[squeak-dev] Protocol extension proposal: Boolean>>asBit ?

Igor Stasenko siguctua at gmail.com
Sat Dec 5 12:38:07 UTC 2009


2009/12/5 Bert Freudenberg <bert at freudenbergs.de>:
> On 05.12.2009, at 11:44, Igor Stasenko wrote:
>>
>> I currently writing a code which looks like:
>>
>> a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]).
>>
>> And i get somewhat tired repeating the same pattern in multiple places.
>> So, i thinking , maybe #asBit convenience method could be useful?
>>
>> True>>asBit
>>  ^ 1
>> False>>asBit
>>  ^ 0
>>
>> so, then, in case of need like above, we could write much shorter expressions:
>> a := some numeric expression + someBoolean asBit.
>>
>> And its much less error prone comparing to #ifTrue:ifFalse:, since i
>> found its relatively easy to make a mess (swapping 1 with 0),
>> especially, when you having negations in expression, because once you see:
>>
>> (someBoolean not ifTrue: [1] ifFalse: [0])
>>
>> you always tempted to write it as:
>>
>> (someBoolean ifTrue: [0] ifFalse: [1]).
>>
>> or as:
>>
>> (someBoolean ifFalse: [1] ifTrue: [0]).
>>
>> but once you start playing with it, its very easy to shoot into own
>> feet if you are not careful.
>>
>> But if we could add #asBit, then we could write:
>>
>> someBoolean not asBit
>>
>> which is much more:
>> a) concise & cleaner
>> b) error proof
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
> Wouldn't #asInteger be more appropriate?
>

Probably. But i choose a 'bit', because booleans is an enumeration
type, not a number ,
and its hard to expect that something which is not a number can be
converted to number.
Another reason why i cautious about #asInteger, that it is already
exists & used widely and probably
introducing it into boolean classes can be fatal to some applications.

Maybe i'm overly cautious about that, if so, then #asInteger is just fine.


> - Bert -



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list