2009/12/5 David T. Lewis <lewis at mail.msen.com>:
> 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.
>

C is much closer to hardware than smalltalk. And we all know, that
whatever you type of whatever program you will create in whatever
language, the computers could represent it internally only as a
sequence of bits.

There are also couple things which can be seen as muddy. Consider #sign method:

sign
	"Answer 1 if the receiver is greater than 0, -1 if less than 0, else 0."

	self > 0 ifTrue: [^1].
	self < 0 ifTrue: [^-1].
	^0

which could be also considered as a 'conversion' of boolean
expressions to integer values, because i can implement it as:

sign
  ^ (self > 0) asBit - (self < 0) asBit.

This is not the only place, where boolean values working together with
numerical values.
Consider rounding function(s):

floor
	"Answer the integer nearest the receiver toward negative infinity."

	| truncation |
	truncation := self truncated.
	self >= 0 ifTrue: [^truncation].
	self = truncation
		ifTrue: [^truncation]
		ifFalse: [^truncation - 1]

while we all get used to that rounding works *only* with numbers, it
is impossible to implement them without using boolean algebra (but you
may try, of course).

Moreover, mathematicians using boolean expressions widely for defining
a different weird-looking functions:

f(x) =  {
  (x<0) -x;
  (x>=0) x;
}


So, i wouldn't say that we are first, who guilty by muddying booleans
and numbers. It was happen a lot earlier and much more frequent in
many areas.

> 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.
>
> $0.02
>
> Dave
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.