Mike Meyer <[EMAIL PROTECTED]> wrote: ... > Except you haven't shown that the API was badly designed. You can't > show that it's badly designed, because you don't know the requirements > that the API is meeting.
I can show that an API is badly designed *whatever requirements it might be intended for* if it's self-contradictory: containing a way to CHANGE an attribute to some different value, but not containing any way to SET THAT ATTRIBUTE TO THE RIGHT VALUE from the beginning, is inherently an indicator of bad design, because it needlessly imposes more work on the API's user and forces objects to pass through a transient state in which their attributes are WRONG, or MEANINGLESS. > > 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, > > But we're not dealing with a general case, we're dealing with a > specific case. Just because you can't think of cases where an > attribute being settable doesn't mean it needs to be settable in a > constructor doesn't mean they don't exist. The burden of the proof is on you, of course: show a design situation where it's RIGHT to force API users to do extra work and lead objects through states they're *NOT* meant to be in, because there is no way to build the object correctly from the start, but rather the object must be built in a wrong state and then later coerce it to the state you knew was right since the beginning. There may be languages which are so feeble as to force such behavior (e.g., languages where every new instance has every attribute forced to null even where it makes no sense for a certain attribute to ever be null) but that applies to neither Eiffel nor Python, and all it shows is that some languages are seriously lacking in the tools to allow proper designs to be implemented, not that "all objects must always be generated in the WRONG state" can ever be the RIGHT design. > > 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). > > Actually, the original claim was "more difficult". You've done your > usual trick of reaching an invalid conclusion from what someone said, > then acting as if that's what they said. Congratulations, you've > successfully beaten up the straw man you created. Right: I claim, on the other hand, that YOU are weaselwording, by trying to claim that any class with one extra method is thereby "MORE DIFFICULT" to write -- equating having to write one or two lines of trivial code with "MORE DIFFICULT" would make the "more difficult" totally bereft of any useful meaning in whatever context. I'm currently in an interesting job role, known as "uber technical lead", which is meant to be a sort of a cross between technical manager and ubergeek-guru. Fortunately, my reports are all people of technical excellence as well as personal integrity, so, should I ever ask one of them to explain why he or she did X and not Y, I fully trust they won't try to explain that "doing Y would have been more difficult" when the reality is that it would have involved a line of two of trivial code... if they did, I can assure you that the consequences might be interesting. (Good think I can and do trust them to say, should such a situation ever arise, "DUH! -- I just didn't think of it!", and go fix their code forthwith... just as they've often heard ME say, apologetically, in the much more frequent situations where my objections to some design were misconceived... so, my modest management abilities will not be put to such a difficult test in the foreseeable future;-). Alex -- http://mail.python.org/mailman/listinfo/python-list