Protocol extension proposal: Boolean>>asBit ?
Locked
Protocol extension proposal: Boolean>>asBit ?
 
|
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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Protocol extension proposal: Boolean>>asBit ?
|
|
On Sat, 5 Dec 2009, 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? > It's useful IMO, so I use it whenever I need it. It's in the image with 7/1/2004 timestamp. Levente > 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. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Protocol extension proposal: Boolean>>asBit ?
|
|
In reply to this post by Igor Stasenko
I like the idea.
publish the code with some tests + a bug entry and we include it. Now do you have any idea how the selector could mkae sure that we know that true is one? Because I could never remember that in C. I used stickers on my screen or macros. On Dec 5, 2009, at 11:44 AM, 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. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Protocol extension proposal: Boolean>>asBit ?
|
|
I don't think that something that is not used in Pharo itself should
be included in the core. AFAIK packages like Alien and FFI have their own converter methods for similar things. Lukas 2009/12/5 Stéphane Ducasse <[hidden email]>: > I like the idea. > publish the code with some tests + a bug entry and we include it. > > Now do you have any idea how the selector could mkae sure that we know that true is one? > Because I could never remember that in C. I used stickers on my screen or macros. > > > On Dec 5, 2009, at 11:44 AM, 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. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Protocol extension proposal: Boolean>>asBit ?
|
|
> I don't think that something that is not used in Pharo itself should > be included in the core. AFAIK packages like Alien and FFI have their > own converter methods for similar things. how do they are named in alien or FFI? This is two simple and trivial methods. There are so many other stuff that make no sense to have that I would be ok to keep these ones. > > Lukas > > 2009/12/5 Stéphane Ducasse <[hidden email]>: >> I like the idea. >> publish the code with some tests + a bug entry and we include it. >> >> Now do you have any idea how the selector could mkae sure that we know that true is one? >> Because I could never remember that in C. I used stickers on my screen or macros. >> >> >> On Dec 5, 2009, at 11:44 AM, 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. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Protocol extension proposal: Boolean>>asBit ?
|
|
> how do they are named in alien or FFI?
I don't remember. I just vaguely think that both have convertor methods to transform the object to a low-level representation that can be directly used in external function calls. > This is two simple and trivial methods. There are so many other stuff that make no sense to have that > I would be ok to keep these ones. The question is if the proposed solution is generally useable? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
I understand the motivation and the implementation, but IMNHO the name of the
method should be #asSmallInteger or if you want more general #asNumber. Returning 1 or 0 is not the same thing as returning a bit, except if we agree on creating a class called bit where the operations on it abide to what it is expected for a bit. my .019999... -- Cesar Rabak Em 05/12/2009 08:44, Igor Stasenko < [hidden email] > escreveu: 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/12/5 <[hidden email]> CédrickI understand the motivation and the implementation, but IMNHO the name of the Why not #asBitNumber ?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Cédrick,
I understand the diplomacy of the suggestion and I think it sounds like an interesting compromise. Before we jump at it, let me ask some questions: Does a class called BitNumber exists in the present (core) Pharo hierarchy? Does it makes sense to add a class like this? Which behaviour for BitNumber is not already subsumed by Number? my .0019999... -- Cesar Rabak Em 06/12/2009 11:36, Cédrick Béler < [hidden email] > escreveu: 2009/12/5 <[hidden email]> I understand the motivation and the implementation, but IMNHO the name of the method should be #asSmallInteger or if you want more general #asNumber. Why not #asBitNumber ? Returning 1 or 0 is not the same thing as returning a bit, except if we agree on creating a class called bit where the operations on it abide to what it is expected for a bit. my .019999... Cédrick _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |