Another newbie question

[Alex Martelli]

Mike Meyer <mwm at mired.org> 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