[Self-interest] Block Question

Jecel Assumpcao Jr jecel at merlintec.com
Thu Nov 11 21:02:20 UTC 2021

Luke McNeil wrote on Thu, 11 Nov 2021 00:31:12 -0500
> Interesting.  This inspired me to see if that activation was anything before it became <a dead activation>.
> If I do "Get it" with "(| x = (reflect: [2]) lexicalParent printLine |) x" it prints out 
>       "a mirrors methodActivation(on (lobby) <top level expr>)"
> The object that you get, however, in the GUI quickly turns from that same output to "mirrors deadActivation on <a dead activation>)" as the method returns.
> So maybe some methodActivation object is being made on the lobby, and [2] is being evaluated like a top level expr in this context.
> Further insight is appreciated.

In Smalltalk you can select some text in an text pane and if it is a
valid Smalltalk expression you can "do it", "print it", "inspect it" and
so on. But this loose piece of code doesn't fit into the "everything is
a method in some class" model of the world. So what the system actually
does is to compile the code fragment as the method body for the method
#DoIt in the class of the nil object. It then sends that message and
everything works as normal.

Something related happens when you want to define a new class or change
an existing one. There is a message template shown in the system browser
that gets executed when you change and accept it and the effect of
sending that is to change the class.

For Self things are far simpler since there is a literal syntax for
defining new objects: ( |  ...  | )

When compiling some code that include literal objects there is a slight
complication in that, unlike Smalltalk-80, we don't have globals in
Self. Most objects have either "traits clonable", "traits identity" or
"traits oddball" as an ancestor and all of these inherity from

But if we create an object like ( | a <- 3. b = 4 | ) it won't know any
globals. Passing it a message asking for "traits color" will fail, while
in Smalltalk all code can access the global Color. This is normally a
good thing which allows us to implement the POLA (principle of least
authority) security style in our code if we want. It does, however,
create a "chicken and egg" problem when converting a string represting a
literal object into the actual object.

( | a <- 3. b = ( | parent* = traits clonable. 
                            x <- 7. 
                            y <- 9.
                           dsq = (x*x + y*y)
                         | )
| )

To build the inner object the virtual machine must evaluate "traits
clonable", but in what context should it do so? In the half-built inner
object itself? In the unfinished outer object? Even when the outer
object is working, it still won't understand "traits clonable". The
inner object, on the other hand, will understand this message but only
because the message was understood by someone else while it was being

The solution that was adopted was to create a special Lobby object and
evaluate expressions like this one there. And this is what you are

-- Jecel

More information about the Self-interest mailing list