[Pharo-project] Compiler pedantic about ifNotNil: argument
siguctua at gmail.com
Mon Oct 11 12:30:24 EDT 2010
2010/10/11 Peter Hugosson-Miller <oldmanlink at 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.
> 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.
> On Mon, Oct 11, 2010 at 5:03 PM, Stéphane Ducasse
> <stephane.ducasse at 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 at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev