Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 07 Aug 2013 20:23:26 +0200
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: [Math] Fluent API, inheritance and immutability
Message-ID: <e554b3c1e1ea16ade52b4aaf518cbe47@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: eir; whitelist
X-Virus-Scanned: clamav-milter 0.97.1-exp at eir
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

Hi.

It seems that each two of those concepts are at odds with
the third one.

E.g. you can have a fluent API and immutability, but this
then prevents you from defining fluent API methods in a base
class because immutability requires creating a new object
(but the base class cannot know how to "build" a subclass).

Dropping immutability would allow to define "withXxx" at the
hierarchy level where they belong because the fluent methods
modify instance fields (and return an existing "this").
Whereas keeping immutability requires that all "withXxx" are
always redefined at the bottom level of the hierarchy.

Also, if a base class is "abstract", no fluent method can be
defined in it, since it cannot be instantiated. This also
leads to the situation where the (re)initialization of fields
that belong to the base class must be delegated to "withXxx"
methods in all the subclasses.

Thus, in this particular case, immutability entails code
duplication.

I wonder whether it would be possible to have the best of all
worlds by
1. dropping immutability of the instance fields,
2. requiring that all classes participating in the fluent API
    implement a copy constructor,
3. requiring that all non abstract classes implement a "copy"
    method (whose contract is to return a fresh copy).
Hence, code that would like to ensure that it is the sole owner
of an object would be able to call the "copy" method on a
mutable instance that would have been constructed with the
fluent API.

[One a side note: that proposal would also seem to reduce the
overhead (however small that may be) of creating a new object
for each modification, as well as allow usage in situations where
creating a new instance would be undesirable e.g.:
Applying a "withXxx" method on an object stored in a collection
would create a local instance, and require that it be assigned back
into the collection, preventing a language construct such as
"foreach" loops.]

I know that dropping immutability seems a step backwards from what
were trying to achieve in Commons Math but it seems that we must
let go of something (and security could be retained by unit tests
that check the contract of "copy")

If I'm missing something obvious, please let me know!

Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org