commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Fluent API, inheritance and immutability
Date Wed, 14 Aug 2013 00:10:24 GMT

> [...]
>> 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 
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 
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,

> [...]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message