On Sat, Dec 5, 2009 at 11:18 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
> > On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
> > >
> > >>>>>> "Bert" == Bert Freudenberg <bert at freudenbergs.de> writes:
> > >
> > > Bert> I don't think it would break any sane application. #asInteger is
> > > Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect
> it to
> > > Bert> return an instance of Bit.
> > >
> > > Bert> I have not really felt the need for such a method, but I can see
> how
> > > Bert> it's tempting to have, in particular when porting code.
> > >
> > > It's also "according to who".  0 as false, 1 as true is only one
> encoding,
> > > and clearly not universal.  I've worked with systems where 0 is false,
> > > and -1 is true.
> >
> > I knew someone would bring this up ;) I also like to KISS.
> >
> > This is not about internal representation, but about doing arithmetic
> with
> > booleans. I don't think any other mapping than "true asInteger = 1" and
> > "false asInteger = 0" makes sense in that context.
>
> I don't think that arithmetic with booleans makes sense in any context.
>
> Is this convenience method really worth muddying up the distinction between
> numbers and booleans? Think of all the C programmers with bad habits
> (like me for example) who have had to stop and think twice about assuming
> that a number means the same thing as true or false.
>
> It seems to me that maintaining a clear distinction between numbers and
> booleans is a Good Idea even if it does require some extra typing.
>

yes, yes.  But real Smalltalk programs have to interface with external
programming languages, typically through a C-inlfuenced ABI.  In that
context it makes sense.  I second Bert's proposal,  true asInteger == 1 and:
[false asInteger == 0].


>
> $0.02
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091205/e6639720/attachment.htm