On Fri, 16 Oct 1998, Tyler Close wrote:
>
> The third point is also irrevelant because
> the type of method dispatch that E uses means that E will never be able to
> use function tables anyway. (At the very best, E will have to use some form
> of hashtable such as a wire.)
I'm not clear why you said that -- exactly what kind of mechanism are you thinking of as a function table, and how does E preclude it? Could E use what you call function tables if the programmer provided extra static typing information in "define" expressions?
And -- out of curiosity -- what is a "wire" as you use it here?
> Well, here's a vote for doing away with inheritance. Wow, think of the
> millions of hours of developer time spent trying to create inheritance tree
> taxonomies. Talk about a simple yet powerful language!
So here finally is the response i have been intending to make to this particular line of discussion for some time, but haven't caught up to:
I think the issue is nearly moot. In a strongly-typed language inheritance is a clearly-defined thing that gives you the specific feature of type compatibility. In a dynamically-typed language the whole issue is blurrier anyway.
When you reuse code by aggregating, you essentially have to do delegation. And the only thing "inheritance" really is in this language is a convenience that automates some of the drudgery of delegation for you. That is, it's no worse than what you want anyway, and certainly important to the goal of presenting beginners with concepts they are familiar with.
What advantage could *removing* inheritance possibly give you?
!ping