commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Fluent API, inheritance and immutability
Date Wed, 07 Aug 2013 22:33:21 GMT
On Wed, 7 Aug 2013 13:39:41 -0700, Ted Dunning wrote:
> This is often dealt with by using builder classes and not putting all 
> the
> fluent methods on the objects being constructed.

Builders seem fine when no inheritance is involved: all fields are
duplicated (and mutable) in the builder, then an immutable instance
is created from the contents of the builder instance.
But when fields are spread in several classes of a hierarchy, how to
combine the respective builders?
Having one builder at the bottom of the hierarchy would work, but
defeats the purpose of initializing the field with the fluent method
defined in the class where the field is declared.

> The other way to deal with this is to use a covariant return type.  
> For
> instance, there is no guarantee that Pattern.compile returns any 
> particular
> class other than that it returns a sub-class of Pattern.

The here purpose is the fluent method always returns the actual type.
This can be nicely solved with generics (cf. "self-type") provided that
the "this" reference is retained (which is not true with immutability).

> Do you have a specific example of the problem you are alluding to?

Yes: see the classes in "o.a.c.m.fitting.leastsquares".
I strongly suspect that a lot of the code dedicated to the fluent API
could be removed if immutability is dropped.


Gilles

>
> On Wed, Aug 7, 2013 at 11:23 AM, Gilles 
> <gilles@harfang.homelinux.org>wrote:
>
>> 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


Mime
View raw message