[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: <boolean> <true> & <false>
- To: email@example.com, firstname.lastname@example.org
- Subject: Re: <boolean> <true> & <false>
- From: email@example.com (Andrew LM Shalit)
- Date: Mon, 30 Nov 1992 10:22:44 -0500
At 26 Nov 16:50 GMT, firstname.lastname@example.org wrote:
> >> ...If you have separate classes for true & false then its possible
> >> to define the basic control structures using polymorphism on #t &
> >> #f and lambda (method)....
> >While this is a simplification in theory, I don't think it would simplify
> >the practice of programming in Dylan. It might be different in Self and
> >If you allow the user to define methods on IF, then it also makes things
> >much harder for the compiler.
> > -Andrew
> I'm not sugesting one replace the IF special form by methods. The
> compiler can in-line the Smalltalk-style methods/lambda version of IF, but then
> debugging the code reveals that the compiler has treated the IF message
> specially. So if one is concerned about efficiency then use hard-wired control
> My feeling is that if you introduce a class <boolean> which allows
> you to specialise methods on <boolean> and non-<boolean> you should introduce
> <true> & <false>, since its likely you will want to specialise methods on
> <true> & <false>.
Do you want <true> and <false> to be subclassable? If not, why not just use
(singleton #t) and (singleton #f) instead? If so, do instances of subclasses
of <false> also appear as false to IF?