[Pharo-project] Compiler pedantic about ifNotNil: argument

Peter Hugosson-Miller oldmanlink at gmail.com
Mon Oct 11 11:42:05 EDT 2010

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.


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
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101011/9b3a7f18/attachment-0001.html>

More information about the Pharo-dev mailing list