[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
block parents (was: multicasting)
Rainer Blome wrote:
> [ | :element. | element ifTrue: 'OK' False: 'Huh?' ] value: true
> => 'OK'.
Remember that there are really four objects involved in
every block use: the block object itself which is a literal
of the current method, a block activation which is what is
actually pushed on the stack when the bytecode to push
the block is executed (an implicit cloning much like what
happens when methods are fetched from slots), a method
(called value, value: or etc...) which holds the code
that is listed above and a method activation that actually
executes the code when the value message is sent to the
This means that the code above is roughly like
( | lexicalParent.
parent* = blockParent.
value: = ( | :element | element ifTrue: 'OK' False: 'Huh?' ).
^ clone lexicalParent: _CurrentActivation
) value: true
The details aren't important, just the fact that when you
write [...] in your code you are actually writing the
body of a value method.
> [ | :element*. | ifTrue: 'OK' False: 'Huh?' ] value: true
> => Syntax error.
Every method activation has an implicit :self* slot, except
for the method activation of the value method of a block
that has a :<lexicalParent>* slot instead. These slots
can't be produced from the normal Self syntax, but only
created by the virtual machine.
> [ | :element. environment*. | environment: element.
> ifTrue: 'OK' False: 'Huh?' ] value: true
> => Lookup error: ifTrue not found.
The environment* slot is actually a slot in the value
method, and its clone the value method activation. I can't
test this, but I would bet that no method/method activations
can have working dynamic parent slots. From the language
definition they should, so it looks like an implementation
error. I don't think the effort to "fix" this error is
worth it, however, so I would suggest that you stick with
other solutions to your problem.