"Brian Brown" <
[hidden email]> wrote:
> Looking at ProtoObject>>ifNotNil: ifNotNilBlock
> "Evaluate the block, unless I'm == nil (q.v.)"
>
> ^ ifNotNilBlock valueWithPossibleArgs: {self}ifNotNil:
>
>
> ... which is invoked if the receiver is not nil, I would expect the
> following to work:
>
> 5 ifNotNil: [:e | e] to return 5, but what I get is:
>
> argument of ifNotNil: must be a 0-argument block
>
>
> However, if first store the block in a temp:
>
> ab := [:e | e]
>
> 5 ifNotNil: ab.
>
>
> returns 5
>
> I don't understand what the difference is between these; could some
> kind soul enlighten me as what is happening?
>
>
Very interesting. There should be no difference between the two
statements you mention and the very fact that there is should be
understood as a hint thatwe may have a new compilation bug.
In Squeak 3.7 the two statements of your example are both
erroneous, forthefirst one the compiler gives a message,
thesecond one brings up the debugger.
In Squeak 3.7 the definition of ifNotNil: was:
ifNotNil: ifNotNilBlock
"Evaluate the block, unless I'm == nil (q.v.)"
^ ifNotNilBlock value
The difference to newer version is that in 3.7 no support
for optional block arguments was present. In 3.9 it is
present and in my opinion the compiler was not
appropriately adapted.
Class MessageNode has two class variables that are relevant for
that problem:
MacroSelectors
an array of message selectors that are inlined or otherwise
transformed.
MacroTransformers
an array of message selectors for messages in MethodMode that
implement the code optimization.
These class variables and others are initialized in
MethodNode class>initialize
and I think a change there would fix the problem.
The really important question is however:
Was the introduction of optional arguments for ifNotNil:
(and others) a good change when that change requires
the removal of a code transformation?
Comments from our compiler specialists are of course
welcome.
For me it is quite clear that we have a compiler bug here,
but I hesitate to propose a fix. Shall me modify thecompiler
or shall we go back to an earlier definition of ifNotNil: ?
Hope this will help
Boris
Locked
