Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> > > Sure.  But I was thinking the real advantage of my scheme above was not
> > > the potential added speed-up but the added structure to the program. 
> > > The compiler would catch misuses of selectors.
> How can you guarantee it is a misue? There is no reason one shouldn't
> use the same selector name for different purposes, some returning a
> value and some not. It all depends on how your code reads and what you
> want to mean by it. I really don't think you can attach this sort of
> meaning to a selector.

In my view, "same selector for different purposes" are different
selectors with the same name.  For example, Color#red and ColorClass#red
are different selectors because the first means return the amount of red
while the second means return the color red.  They are not polymorphic
with each other.  In Squid, you can distinguish between two different
selectors with the same name by prefixing it (like above) with the
behavior that defines (introduces) it.  To override a selector you have
to inherit from its defining behavior (multiple inheritance is allowed).
 To send a selector you have to import its defining behavior.

You may think this is too restricting, making polymorphism a pain.  But
I believe these restrictions will yield better-structured,
more-understandable programs, making explict the intentions of the
programmer.  If he wants to make his class polymophic with some
selectors, he is really inheriting the interface of those selectors and
possibly related selectors, and may even want to implement some of them
the same way.  All those selectors should be separated out into an
independent behavior so senders only have to import that interface and
implementors can inherit from that behavior without duplicating common
code.

Cheers,
Anthony