Another newbie question

[Mike Meyer]

aleax at mail.comcast.net (Alex Martelli) writes:
> 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.

Nope. If the requirements are that all objects start in the same
meaningful state, then you simply create them in that state. There's
no need to provide a facility to to set the initial state, and they
never go through a meaningless state either.

>> >  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.

You're doing it again - I never claimed that there was any such API
requirement. You've reached this conclusion on your own, by adding
requirements to the design that I never discussed. If you want to
someone to proof this straw man, you'll have to do it yourself.

>> > 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.

As I already explained, the entire change was trivial, so any extra
work is of course trivial. This extra work is exactly what I meant
when I said "more difficult". You want to play semantic games, and
argue that one trivial change can't be "more difficult" than another,
feel free to do so. But do realize that you're disproving your
strawmen, not my statement.

         <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.