[Pharo-project] 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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 < siguctua@gmail.com > 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/12/5 <csrabak@bol.com.br>
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
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 < cdrick65@gmail.com > escreveu: 2009/12/5 <csrabak@bol.com.br> 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
participants (6)
-
csrabak＠bol.com.br -
Cédrick Béler -
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
Stéphane Ducasse