Compiling a role name into a message to self

Tom Phoenix rootbeer at
Mon Nov 19 19:05:49 UTC 2007

On 11/19/07, Trygve Reenskaug <trygver at> wrote:

>  I am just completing an experiment where I am programming with roles. A
> role name stands for one or more objects; the actual binding occur at run
> time.  Example:
>          (self playerForRole: #currentStar) displayLarge
>  It would be much more readable if I could write something like
>         ¤currentStar displayLarge  or §currentStar displayLarge or  :-)
> currentStar displayLarge or ...
>  currentStar is a role name, self playerForRole: searches down the stack to
> find the appropriate object binding .

When does it search down the stack? You said "at run time," but
there's more than one possibility. For example, if I wrote code like

  ¤currentPresident say: 'I hate my job.'.
  ¤currentPresident resign.
  ¤currentPresident takeOathOfOffice.

...would you want to search three times to identify the target object?
It would be a nice optimization to search only once, but it might
surprise somebody when the object changes. The King is dead, long live
the King!

If you wish to make that optimization, here's a fairly easy way to
implement it: Compile the method as if it had one extra named variable
for each ¤rolePlayer. Set each of these variables at the top of the
method code. Treat ¤rolePlayer more-or-less as a read-only variable
after that.

If you would have it look up the ¤rolePlayer each time, you'll simply
do it without the variables. In either case, you'll be sending "secret
messages" that the user didn't write, such as #playerForRole:, so you
should consider what you'll do to make it easy to handle the situation
when you can't identify the ¤currantPersident, or some such, at run

If one ¤rolePlayer can mean many objects, but it's usually just one,
things get more complex. Could it also mean no objects at all? How can
end-user applications, which don't include debugging facilities, deal
with RoleNotFilled errors at run time? Do you need a RolePlayer class
to manage these things?

And the biggest question of all: Is the benefit of roles sufficient to
outweigh this added complexity? It might be....

Good luck with it!

--Tom Phoenix

More information about the Squeak-dev mailing list