Loose type checking in E

[shap@eros.cis.upenn.edu]

Ping writes:

> That is, what do you do when someone has handed you the ability to
> create a certain type of object with some useful behaviour, and you
> just want to extend that behaviour a little?

First, it's never that simple in languages with access protection.
Inevitably the API exported by the object is not quite enough to do
any serious extension.

Second, inheritance is just one of many possible solutions.  Another,
which avoids the mindless rewriting you mentioned, is ``delegation.''
Given a choice between delegation and inheritance, my feeling is that
I'ld prefer delegation.  Fortunately, it isn't either/or.

Better still is specific delegation, wherein one object says:

   I want to publish methods X, Y, Z.  What it means to invoke my X,
   Y, Z methods is to invoke the X method of this here member object.

> Lead me, as you would lead a Java-head well-steeped in the virtues
> of inheritance, through a procedure by which i can take a design
> typically done with inheritance, and lose no convenience...

You are begging an important question.  Even if you *do* lose
convenience, this is not a good reason to add an ill-founded feature
to the language.  Also, I think you are setting up the wrong
comparison.  The comparison here is not between C++/Java and E.  It's
between Visual Basic and E.  If MarkM is serious about the millions of
users objective, the C++ and Java audience becomes irrelevant.

With that as preamble, I don't conceded the loss of convenience issue.
Neither Tyler nor I has simply said ``drop inheritance.''  Both of us
have said ``use interfaces instead.''  This is one possible proposal;
there are certainly be others -- delegation comes to mind.

So, we should indeed do the exercise you propose, but let's first work
out the selection of language feature set rather than do the
evaluation in the middle of things.

I shall answer your example question in separate mail.


Jonathan