[erlang-questions] Fear and Loathing in Programming La La Land
Thu Apr 5 02:39:32 CEST 2012
On 5/04/2012, at 11:50 AM, Jan Burse wrote:
> I don't think we can make a case against setters.
The thing is that the interface needs to be designed based on
the needs of clients; what is the thing _for_? A lot of existing
Smalltalk code is riddled with setters, perhaps because of the
ideology called 'self-encapsulation' which says that an object
should even get or set its *own* fields directly, but always
through getters and setters so that they can be overridden in
subclasses &c. For me, the question is always "does it make
sense for *client* code to change *just* this one property."
I have consistently found that it pays to remove every other
setter. For example, if you look at the Simulation example in
the Smalltalk Blue Book, you'll find numerical integrators with
plenty of setters. Taking those out led to a cleaner design, in
which integrators could be applied as functions, and in which it
was possible to compute integrals in parallel.
> But we can make a case against the research paper
> that has spun this thread: varargs are a third option
> in creating an API.
Varargs, Python-style dictionaries, JSON objects, XML, ...,
Prolog and Erlang option lists, ...
If you look at the OpenJDK Parser class, you'll see that it
uses a Factory object and the Factory object has a Context
parameter holding all sorts of stuff.
A particularly noteworthy example of 'Configuration Parameter'
is the POSIX threads interface, where for each pthread_FOO
major type there is a pthread_FOO_attr type; you initialise
an attribute object, set any fields you like (OK, because it
_is_ at this stage just a loose bundle of properties), and
then pass it to the creation function for pthread_FOO.
What this does is to make the set of configuration options
*open*, so that different implementations can add different
extensions, and new versions of the standard can add new
options, both of which have happened.
The alternating keys and values thing was found in SunView.
More information about the erlang-questions