Loose type checking in E

[Ka-Ping Yee]

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