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, 14 Aug 2013 00:10:24 GMT
Hello.

> [...]
>
>>
>> Looking on the web about fluent API, most design/usage/examples do 
>> not
>> provide immutability: the primary purpose of "fluent" is to chain
>> on-the-fly modifications of an object's properties. [This is the 
>> complete
>> opposite of immutability!]
>
> Well, as the fluent API return an object, there is no reason it is 
> the
> same as the initial one. It is just like String.trim() returns a new
> instance and does not strip the whitespace within the original 
> instance,
> which remains immutable.

Then, there is also "StringBuilder"... :-)

>>
>> [...]
>
> It should surely be documented, but this is a nice feature for me. It
> allows easy copying as a side effect when you really want to set up
> something from a prototype instance. The case Evan wrote about is an
> example of the use case I have in mid: you start by preconfiguring 
> part
> of the algorithm, and at the end you duplicate this prototype in 
> several
> instances that will have only one slight modification each.

Yes, this is useful. But would it hurt to require that the user calls a
"copy" method (to copy the common config and then be free to modify 
what
needs be)?  A shallow copy will provide the same (in)security as
immutability of reference fields to mutable objects. At least, an API
that provides a "shallowCopy()" method is clear about its limitations.

The "shallowCopy" promises users that changes to fields (through the
fluent API) in one optimizer will not propagate to the fields of a 
second
optimizer from which it is a copy.
It also explicitly makes no promise about user-supplied fields.

Would that cover most needs, or did I overlook something?


Best regards,
Gilles

> [...]


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


Mime
View raw message