ØScreenDisplay>>draw:
aGraphicalObject <Line>”draw a line on a screen”ØScreenDisplay>>draw: aGraphicalObject <Arc>”draw an arc on a screen”

This illustrates the
syntax we used. Our class specializers are enclosed in angle brackets. The
VisualWorks Smalltalk compiler had a dormant, postfix, bracketed type
recognition facility already built into it. We simply had to turn it on, and
override a few methods to wire in our multimethod facilities. Any “easter
egg” in the compiler, I think they call it…

Asymmetric
multimethods are preferentially attached or owned by their primary receiver
classes. Symmetric multimethods are owned by none, or all, depending on how
you want to look at it.

As with the
faux-Java example show, our is arguably an “asymmetric” design. Our goal was
to present a symmetric syntax, as CLOS had done, while maintaining (at least
for the time being) asymmetric implementations.

(I’d like to have
made it symmetric, but more compiler hacking would need to be done to carry
this off.)