[Pharo-project] Case of caseOf
I would love if we could slowly deprecate caseOf:
Yes please, remove this source of horror ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2008/9/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I would love if we could slowly deprecate caseOf:
This C-ism are built-in compiler optimization. I would love, as well, to move all optimizations in separate class and make it optional. I see no real usage of #caseOf: or #caseOf:otherwise: in Pharo - just in single place (ProcessBrowser). However, i see a multiple places in Croquet image where it is used in a form of: cmd := data at: 1. cases := { .... }. cmd caseOf: cases. Which also proves that it not worth using it, because it can be simply replaced by single line: self perform: (cmdSelectors at: (data at:1) ) withPossibleArguments: (Array with: data).
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Mon, 22 Sep 2008 17:25:16 +0300 "Igor Stasenko" <siguctua@gmail.com> wrote:
I see no real usage of #caseOf: or #caseOf:otherwise: in Pharo - just in single place (ProcessBrowser). However, i see a multiple places in Croquet image where it is used in a form of:
cmd := data at: 1. cases := { .... }. cmd caseOf: cases.
Which also proves that it not worth using it, because it can be simply replaced by single line:
Yes, it *can* be replaced, but *should* it be replaced? The three lines above are way more readable than the one line below.
self perform: (cmdSelectors at: (data at:1) ) withPossibleArguments: (Array with: data).
How about going after the creator of the data array first? It seems to be a primitive data structure wanting to become a MessageSend or something similar. Just making smalltalk, s.
2008/9/22 Stefan Schmiedl <s@xss.de>:
On Mon, 22 Sep 2008 17:25:16 +0300 "Igor Stasenko" <siguctua@gmail.com> wrote:
I see no real usage of #caseOf: or #caseOf:otherwise: in Pharo - just in single place (ProcessBrowser). However, i see a multiple places in Croquet image where it is used in a form of:
cmd := data at: 1. cases := { .... }. cmd caseOf: cases.
Which also proves that it not worth using it, because it can be simply replaced by single line:
Yes, it *can* be replaced, but *should* it be replaced? The three lines above are way more readable than the one line below.
You forgot, that there is more than just three lines , because between curly braces you'll have something like: caseA -> [ self dosomethingWithData ]. caseB -> [ self dosomethingElseWithData ]. ... It is completely different from smalltalk style, where we have many methods but containing few lines of code. and i doubt that such 'not-so-three' lines are more readable than line , presented by me :)
self perform: (cmdSelectors at: (data at:1) ) withPossibleArguments: (Array with: data).
How about going after the creator of the data array first? It seems to be a primitive data structure wanting to become a MessageSend or something similar.
it is used in places where code encoding/decoding data packets (my guess), and its first byte indicating a packet type, or something like that. I suspecting that this code was ported to smalltalk from C, and 'caseOf:' used simply because it is easier to port things blindly, in same manner as it was written in original, than doing hard work rewriting code to accommodate in new language/environment. Of course, i can't blame people doing this. Sometimes we need results fast. And when things done & working, we need something else to do (fast as well) :)
Just making smalltalk, s.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Mon, 22 Sep 2008 20:03:31 +0300 "Igor Stasenko" <siguctua@gmail.com> wrote:
and i doubt that such 'not-so-three' lines are more readable than line , presented by me :)
true. my oversight.
I suspecting that this code was ported to smalltalk from C, and 'caseOf:' used simply because it is easier to port things blindly, in same manner as it was written in original, than doing hard work rewriting code to accommodate in new language/environment.
Or the original implementor was under the impression/constraint that only "primitive" data types could be transmitted.
Of course, i can't blame people doing this. Sometimes we need results fast. And when things done & working, we need something else to do (fast as well) :)
hmm... I wonder about the long-term effects of this approach though. This instant-gratification-code is what a friend of mine usually left around for me to take care of and clean up and it tends to mutate into dangerous beasts when left unattended for a while. just making smalltalk, s.
On 22.09.2008, at 19:50, Stefan Schmiedl wrote:
Of course, i can't blame people doing this. Sometimes we need results fast. And when things done & working, we need something else to do (fast as well) :)
hmm... I wonder about the long-term effects of this approach though. This instant-gratification-code is what a friend of mine usually left around for me to take care of and clean up and it tends to mutate into dangerous beasts when left unattended for a while.
One could describe the coding style of much of Morphic and all of Etoys as "programming as if there would be no tommorow" ;-) Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On Mon, 22 Sep 2008 19:59:24 +0200 Marcus Denker <denker@iam.unibe.ch> wrote:
On 22.09.2008, at 19:50, Stefan Schmiedl wrote:
Of course, i can't blame people doing this. Sometimes we need results fast. And when things done & working, we need something else to do (fast as well) :)
hmm... I wonder about the long-term effects of this approach though. This instant-gratification-code is what a friend of mine usually left around for me to take care of and clean up and it tends to mutate into dangerous beasts when left unattended for a while.
One could describe the coding style of much of Morphic and all of Etoys as "programming as if there would be no tommorow" ;-)
seems like a good way to make a self-fulfillling prophecy ... but maybe I'm just getting too old for this stuff :-) s.
2008/9/22 Marcus Denker <denker@iam.unibe.ch>:
On 22.09.2008, at 19:50, Stefan Schmiedl wrote:
Of course, i can't blame people doing this. Sometimes we need results fast. And when things done & working, we need something else to do (fast as well) :)
hmm... I wonder about the long-term effects of this approach though. This instant-gratification-code is what a friend of mine usually left around for me to take care of and clean up and it tends to mutate into dangerous beasts when left unattended for a while.
One could describe the coding style of much of Morphic and all of Etoys as "programming as if there would be no tommorow" ;-)
such programming style can be titled as well as: 'doing the job, we're paid for, but not a bit more'. :)
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Igor Stasenko -
Lukas Renggli -
Marcus Denker -
Stefan Schmiedl -
Stéphane Ducasse