Mike Meyer <[EMAIL PROTECTED]> wrote: ... > > Claim: doing X makes Y hard. > > Harder, not hard.
The specific wording you used was "MORE DIFFICULT". > > Here is an example of doing X where Y is easy > > Y is very easy in any case. Making it incrementally harder doesn't > make it hard - it's still very easy. If it's very easy, then going out of your way, as you did, to claim it's "MORE DIFFICULT" (you did not use the words "incrementally harder") is rather weird. There's no DIFFICULTY -- sure, if you have ANY one extra trivial method there IS ``extra work'' (a few seconds to write the trivial method and its unittest), but no extra DIFFICULTY. Moreover, I believe I vindicated attribute-setters (and their lack of difficulty) specifically by pointing out the trivial pattern which lets you make them easily, by using a constructor that you must have anyway in a good design (if attributes are worth setting on the fly, they're worth setting at the birth of an instance) and a state-copying method (which is always a good idea for mutable-instance classes). Assuming this wasn't obvious at the start to all readers, I may thus have hoped to have taught something to some reader -- an unusual and pleasant fallout from a mostly "polemical" thread, since often such threads are not very instructive. On that vein, I'll continue by pointing out that there may well be opportunities for optimization -- constructing a new instance is easy, but in some cases, depending on the implementation details, there may be faster approaches. That's most of the case for our using languages with modifiable data rather than pure functional ones, after all...: that changing data (rather than always having to make new objects) sometimes affords better performance. Still, let's not optimize *prematurely*!-) Alex -- http://mail.python.org/mailman/listinfo/python-list
