Re: Snyder's proposal

[Snyder%hplabs.csnet@csnet-relay.arpa]

> We've been too quiet lately.

I agree.  We still are.

> In some sense the
> use of "call-method" and "apply-method" which explictly name the class
> where the system should find a method to make subclasses even more
> dependent upon the details of the supers.  One must know which class
> will be fielding the  equivalent of "send super" while Loops/SmallTalk
> discovers that at run time and Flavors discovers that at compile time.

One possibility is to allow the name of the superclass to be omitted, and
allow the system to figure out which superclass's method to invoke.  To be
consistent with the rest of the proposal, I would make this determination at
the time the subclass is defined.  (The general philosophy is that the
language definition does not bend over backwards to support incremental
development, but of course a "programming environment" is free to do so.)

> One thing in favor of Snyder's system (which he fails to mention) is
> that  IV lookups can be compiled very efficiently without the use of
> permutation tables as in Flavors.   

That is correct.

> I think of Snyder's scheme as a system that gives lots of support for
> implementing inheritance by sending messages to implicit parts which
> correspond to instances of each immediate super.  For example, take his
> example of a "child" class with "parent1", "parent2", and "parent3"
> supers.  One can rephrase the example in SmallTalk/Loops/Flavor terms as
> child having 3 "hidden" ivs initialized as initialized instances of
> "parent1", "parent2" and "parent3".   Then certain messages are received
> by a "child" which in turn forward the messages to the appropriate
> hidden iv.  Is this a reasonable way to view the proposal?

That is an accurate model.
-------