Loose type checking in E
Mon, 26 Oct 1998 11:31:22 -0800 (PST)
On Sat, 24 Oct 1998 email@example.com 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.