Mike Meyer <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
