On 06.12.2009, at 00:36, Igor Stasenko wrote:
> 
> 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.

I hope you're not actually proposing to re-implement the above methods using #asBit (or #asInteger, for that matter) ...

- Bert -