An era ends: Pharo is done with ifNotNilDo:

There was one little thing that I found unnecessarily hard in porting code between squeak and other Smalltalk dialects. It had a long standing “bug” in that it handled sends of ifNotNil:with a one-argument block differently than the source code of ifNotNil:.
The problem was that if you did something like:

anObject ifNotNil: [:obj| obj doSomething].

and anObject was not nil, you got an exception instead of the result of doSomething. This bug was known for many years and nobody ever fixed it. Since the Squeak compiler never runs the sourcecode of ifNotNil:, but runs a primitive instead, it was surprising to see the exception because the source code of the method does handle one-argument blocks as well as zero-argument blocks.
In some newsgroup or mailing list (I can’t really remember) was told to use ifNotNilDo: for my purposes, which is not present in any of the Smalltalk dialects that I use.
In Pharo it’s been fixed long ago, and today somebody removed all sends of ifNotNilDo:, so the era of one of my “major small Squeak annoyances” finally completely ends today and ifNotNilDo: is history, at least in Pharo.


3 thoughts on “An era ends: Pharo is done with ifNotNilDo:

  1. Cleaning up code to improve it and make it more consistent is never, never, ever jumping off of a bridge.

    “if” and “case” statements are a fact of life in real systems and in virtual machines where the metal hits the road. Sure it’s not ideal or even necessarily optimal (that can actually depends on how a compiler translates the code) but I’m all for ensuring the consistency of the message protocols “if*Nil:*”.

    In this case those jumping off the bridge are doing so with a bungee cord attached and are having a heck of a great time!

    It of course would be better if the low level primitive was “compiled” from the method source so that changes in the method source would be reflected in the virtual machine. That is the way forward with ZokuTalk.

    Also the issue over the number of arguments a block being passed in has can be resolved with a smart compiler that compiles multiple versions of the method, one for one argument, one for no arguments. Slate has some provisions for this if I recall.

    Innovation is the future.

    I worked with one of the founders of Smalltalk for almost a year back to back facing each other off over the “if*Nil:*” protocol question. While I lost that skirmish and had to remove about 600 senders of “if*Nil:*” I had added the war for powerful and consistent “if*Nil:*” message protocols has been victorious in just about all Smalltalk systems. The reason is that “if*Nil:*” is about concise and clear testing of object existence.

    I’m very happy with this new development in Pharo’s quest for clear, clean, powerful and consistent “if*Nil:*” semantics. Thanks!


    Peter William Lount

  2. Amusing. I personally hate it when a method takes a variable number of parameters….implementing code to do this produces ridiculous code (numargs =1 ifTrue: []. numargs =2 … etc) and it makes optimization that much harder to do.

    But I guess Pharo is all about jumping off the bridge because everyone else is doing it too, so I shouldn’t be surprised.

    1. John,

      no, it’s about being consistent with other Smalltalk dialects, and, if I remember correctly, to remain Smalltalk-80 compatible.

      I am a friend of readable code as well, and I don’t like variable argument lists as well, but the method ifNotNilDo: always has exactly one argument, a block. But somewhere deep down in the system there is of course an if statement that decides whether to send value or value: to the block. That’s probably ugly. But it’s one ugly place in exchange for a few hundred ugly places in users’ code.

      I guess 98% of all uses of ifNotNilDo: use a one-argument block anyways, since that’s what the method is all about: do soemwthing with an object only if it’s not nil. So I guess it wouldn’t really hurt if the method couldn’t deal with zero argument blocks…


Comments are closed.