Another newbie question

[Alex Martelli]

Mike Meyer <mwm at mired.org> wrote:

> aleax at mail.comcast.net (Alex Martelli) writes:
> >     def setRho(self, rho):
> >         c = self.fromPolar(rho, self.getTheta())
> >         self.x, self.y = c.x, c.y
> >     def setTheta(self, theta):
> >         c = self.fromPolar(self.getRho(), theta)
> >         self.x, self.y = c.x, c.y
> >
> > That's the maximum possible "difficulty" (...if THIS was a measure of
> > real "difficulty" in programming, I doubt our jobs would be as well paid
> > as they are...;-) -- it's going to be even less if we need anyway to
> > have a method to copy a CoordinatePair instance from another, such as
> 
> It's a trivial example. Incremental extra work is pretty much
> guaranteed to be trivial as well.

You appear not to see that this triviality generalizes.  Given any set
of related attributes that among them determine non-redundantly and
uniquely the value of an instance (mathematically equivalent to forming
a primary key in a normal-form relational table), if it's at all
interesting to let those attributes be manipulated for a mutable
instance, if must be at least as important to offer an alternative ctor
or factory to create the instance from those attributes (and that
applies at least as strongly to the case of immutable instances).

Given that you have such a factory, *whatever its internal complexity*,
the supplementary amount of work to produce a setter for any subset of
the given attributes, whatever the internal representation of state used
for the instance, is bounded and indeed trivial:
a. create a new instance by calling the factory with the values of the
attributes being those of the existing instance (for attributes which
are not being changed by the current method) and the new value being set
(for attributes which are being set by the current method);
b. copy the internal state (whatever its representation may be) from the
new instance to the existing one (for many cases of classes with mutable
instances, you will already have a 'copyFrom' method doing this, anyway,
because it's useful in so many other usage contexts).

That's it -- you're done.  No *DIFFICULTY* -- indeed, a situation close
enough to boilerplate that if I found myself writing a framework with
multiple such classes I'd seriously consider refactoring it upwards into
a custom metaclass or the like, just because I dislike boilerplate as a
matter of principle.

 
> > Really, I don't think this makes a good poster child for your "attribute
> > mutators make life more difficult" campaign...;-)
> 
> The claim is that there exists cases where that's true. This cases
> demonstrates the existence of such cases. That the sample is trivial
> means the difficulty is trivial, so yeah, it's a miserable poster
> child. But it's a perfectly adequate existence proof.

You appear to be laboring under the serious misapprehension that you
have demonstrate any DIFFICULTY whatsoever in writing mutators
(specifically attribute-setters).  Let me break the bad news to you as
diplomatically as I can: you have not.  All that your cherished example
demonstrates is: if you're going to write a method, that method will
need a body of at least one or two statements - in this case, I've shown
(both in the single concrete example, and in the generalized code) that
IF a set of attributes is interesting enough to warrant building a new
instance based on them (if it is totally uninteresting instead, then
imagining that you have to allow such attributes to be MUTATED on an
existing instance, while forbidding them to be ORIGINALLY SET to create
a new instance, borders on the delusional -- what cases would make the
former but not the latter an important functionality?!), THEN
implementing mutators (setters for those attributes) is trivially EASY
(the converse of DIFFICULT) -- the couple of statements in the attribute
setters' bodies are so trivial that they're obviously correct, assuming
just correctness of the factory and the state-copying methods.


Alex