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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
