Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
I think that for typing in a transcript experessions when you want to experiment with something selectors are fun but not in method body. But I know that this is not a really good argument. Just feeling. May be we get trapped in our way of thinking.
I personally don't like the ifTrue:ifFalse: related changes, though it's a logical change. I probably won't use that feature though. But I like the monadic block <-> keyword selector substitution. Maybe the best is to add a setting/preference to the compiler.
I think this discussion has diverged a lot from the original question, which is to do with the compiler being too pedantic. #ifNotNil: and friends are the selectors of methods which just happen to give the compiler an opportunity for a nice optimization, in the case when the argument that follows is a literal block. In all other cases they can be treated as message sends. If the compiler starts to impose limitations on the language just because some magic selectors can be treated specially, then IMO it is not behaving as it should. Smalltalk is beautiful because it is so simple: everything is an object, and all processing is done by sending messages to objects. Of course, in the interests of speed, we can write a compiler that actually does something different under the covers, like causing a branch in the byte codes instead of sending a message, and of course the cases when that can be done need to be clearly defined. But that does not mean that these magic selectors should be allowed to pose limitations on how they can be used, because then we no longer have Smalltalk, we have Smalltalk-- instead. Now, the above discussion is orthogonal to the questions of what is good style, what is readable, maintainable, understandable to newbies, etc, etc. Those questions are IMO just as important, but they should have nothing do do with what the compiler is supposed to do. If the compiler is being too pedantic, then it should be fixed. Then we can start discussing good style without mixing apples and oranges together. -- Cheers, Peter On Mon, Oct 11, 2010 at 5:03 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I think that for typing in a transcript experessions when you want to experiment with something selectors are fun but not in method body. But I know that this is not a really good argument. Just feeling. May be we get trapped in our way of thinking.
I personally don't like the ifTrue:ifFalse: related changes, though it's a logical change. I probably won't use that feature though. But I like the monadic block <-> keyword selector substitution. Maybe the best is to add a setting/preference to the compiler.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/11 Peter Hugosson-Miller <oldmanlink@gmail.com>:
I think this discussion has diverged a lot from the original question, which is to do with the compiler being too pedantic.
#ifNotNil: and friends are the selectors of methods which just happen to give the compiler an opportunity for a nice optimization, in the case when the argument that follows is a literal block. In all other cases they can be treated as message sends. If the compiler starts to impose limitations on the language just because some magic selectors can be treated specially, then IMO it is not behaving as it should.
+100
Smalltalk is beautiful because it is so simple: everything is an object, and all processing is done by sending messages to objects. Of course, in the interests of speed, we can write a compiler that actually does something different under the covers, like causing a branch in the byte codes instead of sending a message, and of course the cases when that can be done need to be clearly defined. But that does not mean that these magic selectors should be allowed to pose limitations on how they can be used, because then we no longer have Smalltalk, we have Smalltalk-- instead.
+100. You allowed to cheat, just not get caught!
Now, the above discussion is orthogonal to the questions of what is good style, what is readable, maintainable, understandable to newbies, etc, etc. Those questions are IMO just as important, but they should have nothing do do with what the compiler is supposed to do. If the compiler is being too pedantic, then it should be fixed. Then we can start discussing good style without mixing apples and oranges together.
Amen :)
-- Cheers, Peter
On Mon, Oct 11, 2010 at 5:03 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that for typing in a transcript experessions when you want to experiment with something selectors are fun but not in method body. But I know that this is not a really good argument. Just feeling. May be we get trapped in our way of thinking.
I personally don't like the ifTrue:ifFalse: related changes, though it's a logical change. I probably won't use that feature though. But I like the monadic block <-> keyword selector substitution. Maybe the best is to add a setting/preference to the compiler.
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Igor Stasenko -
Peter Hugosson-Miller -
Stéphane Ducasse