Loose type checking in E

Ka-Ping Yee ping@lfw.org
Mon, 26 Oct 1998 11:31:22 -0800 (PST)


On Sat, 24 Oct 1998 shap@eros.cis.upenn.edu wrote:

> 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.

[?] Is inheritance usable when you have no access protection?
E does not have different levels of access protection.  That's why
when talking about inheritance, the successful languages like Python
and Smalltalk are more relevant than C++ and Java, which do.

> Second, inheritance is just one of many possible solutions.  Another,
> which avoids the mindless rewriting you mentioned, is ``delegation.''

Delegation of individual methods by writing stubs for each method can
be tedious and error-prone and unpopular.  But take one step toward
making this task easier and you already have what we are talking about.

[] Inheritance in E *is* delegation.
What i think is getting missed here is that the inheritance mechanism
is nothing but a *macro* which simulates the behaviour of inheritance
by doing delegation.  All that we're debating is how easy or hard we
should make it.

> 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.

You could probably do that with the appropriate macro construct.

> > 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.

[] There exist disadvantages to losing inheritance.
No, i think you misunderstood me.  I see this as a balance between
advantages and disadvantages on both sides, whereas Tyler claimed
specifically that "there aren't *any* other things made inconvenient
by the lack of inheritance, quite the opposite actually" (emphasis
mine).  I am forcing him to support that (IMHO much too) strong claim.

> 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.

[-] The target audience includes C++ and Java programmers.
I don't think so.  C++ and Java are the primary object-oriented
languages right now.  To "get" E and to "get" capabilities, you have
to have at least some understanding of objects.  Therefore, our target
includes the user base of object-oriented languages such as C++, Java,
Python, and so on.  I don't think the average VB programmer is going
to be able to take much advantage of the wonderfulnesses in E without
at least a few learning steps in there.


!ping