Mike Meyer <[EMAIL PROTECTED]> wrote:
...
> It's not my cherished example - it actually came from someone
You picked it to (try and fail to) show that there is DIFFICULTY, which
I showed there isn't.
> else. That you can change the requirements so that there is no extra
> work is immaterial - all you've done is shown that there are examples
> where that don't require extra work. I never said that such examples
> didn't exist. All you've shown - in both the single concrete example
> and in a generalized case - is that any requirement can be changed so
> that it doesn't require any extra work. This doesn't change the fact
> that such cases exist, which is all that I claimed was the case.
Untrue: you claimed that the specific API (allowing attribute-setting)
"makes changing the object more difficult", not the obvious fact that
"there exist APIs so badly designed that they make changing more
difficult". And I showed that, in the GENERAL case, since attributes
worth being made assignable are obviously also worth being made settable
in a constructor of some kind, having settable attributes doesn't and
cannot introduce any DIFFICULTY -- the API with settable attributes only
requires trivial methods, ones presenting no difficulty whatsoever,
which delegate all the real work to methods you'd need anyway
(particularly the obviously-needed constructor or factory).
So, I claim I have totally disproven your claims about difficulty
("extra work", as you're trying to weaselword your way out, might be
writing one or two trivial lines of code, but that's not DIFFICULT, and
the claim you originally made was about DIFFICULTY, not tiny amounts of
trivially easy "extra work" -- as I already mentioned, obviously ANY
method you add is "extra work" for you compared to not adding it, but
the interesting question is whether that entails any DIFFICULTY).
My claim hinges on the fact that constructors are important -- more so,
of course, for immutable instances, but even in the mutable case it's
pretty bad design if the ONLY way to have an instance in the state you
know is right is to make it in a state that's wrong and then call
mutators on it until its state is finally right... obviously it's
important to avoid imposing this busywork on all users of the class. If
you further weaken your claim to "it's possible to design so badly that
everybody involved faces more work and difficulties", I'll most
obviously agree -- but such bad designs need not involve any
attribute-setters, nor does including attribute-setters imply or even
suggest that a design is bad in this way!
Alex
--
http://mail.python.org/mailman/listinfo/python-list
