Jecel Assumpcao Jr wrote:
> 
> On Saturday 19 May 2001 12:47, Paul Fernhout wrote:
> > Jecel, I'd love to hear your comments!
> 
> You rang, sir?

:-)

> First of all, if you look at the dynamic execution frequency of the
> "super" bytecode (where is my Green Book when I need it?) you will note
> that there isn't anything you can do there that will affect overall
> performance.
> 
> And I don't see how you could have an optimization system that would
> transform an "inherited" bytecode into a jump but wouldn't be able to
> just as easily do the same for "super foo" (in a non #foo method). It
> seems to me that you would have all of the same complexities, specially
> having to keep track of any changes to superclasses that might cause
> you to recompile the method with this optimization.

I think the value isn't so much in the call to super (given the rarity
you suggest) as in the effect on the rest of the system. In short, one
could with this approach represent each class as a simple flat
dictionary of methods (or indexed array of methods if selectors were
mapped to indexes). So dispatching could be much simpler, since there is
never a reason to follow a class inheritance hierarchy (except for
super, which is now a direct call to the inherited specific method).

The only recompiling for methods to be done during development (that I
see at the moment) would be for specific methods when a new super method
was inserted above it in a super class somehow. Also, in some cases if a
sublass relationship was enforced, if a method was added to a
superclass, the subclass would need to get an entry in its method
dictionary (or array) updated with a pointer to the new method.

[Note: I'm doing some handwaving here about how to resolve instance
variable indexing which will probably come back to haunt the idea.] 

But, as a deeper issue, one might start forgetting about the notion of
hierarchy of classes all together, and just think about hierarchies of
specific algorithm implementations represented by a certain name for a
tree of method implementations.
 
> [Interesting Stuff on Self (and language design philosophy) snipped]

Thanks for the additional background on Self. I don't understand why
they have so much complexity. Single inheritance seems good enough to me
for the base system. I felt the same way about NewtonScript (which has
two way inheritance). Also, sounds like a sensible philosophy.

> BTW, I am designing a very simple "kernel" protype based language on
> top of which systems compatible with Self or Squeak can be built. This
> is still in the background mode while I finish another project but we
> should swap ideas.

Sure! (Although what's above is my hot idea for the moment).
Well, that and triads and indentational syntax and Forth-like VMs and
modules.

Hope it's going to be under some sort of free software / open source
license!

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com