[E-Lang] Re: inheritance, delegation, mental models for beginners (was: down with `define' (was: newbie syntax: picayune points from a prejudiced programmer))

[Marc Stiegler]

> By the way, there may be an "out" on the subject of inheritance.  The
> MUD programming languages [1] descended from `lpC' use the word
> "inheritance" to mean the thing that we call "delegation".  I would
> consider it valid to provide a delegation mechanism in E and call it
> "inheritance".  Since E is dynamically typed there is no really
> important difference, is there? [2]

Unfortunately, there is an important difference: if the subclass overrides a
method in the superclass, when the superclass calls that method it goes back
out to the subclass's method. With delegation, a delegated-to class call to
the overridden method is directed to the delegated-to class implementation.
So I like your theory, I yearn to accept it, but I can't buy it :-)

In fact, I have thought about designs for a few programs for which
inheritance would make the system easier to understand and maintain, at
least for the first few revs (everyone assures me that after enough revs
this is guaranteed to break down totally and catastrophically :-). The
programs for which this is true are more complicated systems, which is why I
haven't ever actually used inheritance for anything, not even outside the
domain of the book's examples. My apologies for the fact that I can't
remember any of the examples any more, the projects for which inheritance
looked good were just too ambitious for weekend warrioring, I have forgotten
what they were.

In earlier email, Tyler said we could point to the inheritance you can turn
on by setting a special runtime flag and say we have met the checkbox
criterion. I had actually started thinking about that as a strategy for the
book, and for a few brief moments I thought it might be a minimally
acceptable solution.

Sigh. Then I put on another one of the hats I keep in the closet. This was
the hat I used to wear when I was one of a dozen or so "corporate early
adopters" for a moderately large but rather prestigious company: though this
was not my official title, in fact a huge swath of the company would come to
me for reviews of off-mainstream approaches, since I had gathered a little
fame for making wild successes out of off-mainstream technologies (and thus
making them mainstream, the E dream consequence :-)

In this unofficial (unpaid-for) capacity, I was constantly looking for the
"red flag" that would allow me to end the assessment of a new idea by
discarding it. I was a terrifically hard sell, but once sold, you had a
powerful champion in a company that was widely acknowledged as a leader in
its industry. I wore this same hat later when I was VP of the 4th largest
software company in the world.

Having a section on inheritance that ends with "and if you want to use this,
you have to make sure that all the people you hook together in your
distributed network are running with this special command option" is exactly
the red flag I was always looking for.

Argh. Given the choice between no section on inheritance (another red flag),
a section that uses baroque lambda behavior (a dark pink flag, so dark that
marcs2001 cannot tell if it is pink or red), and a section that ends with
this caveat (a scarlet red flag), I am faced with the horrific conclusion
that I will publish the baroque lambda behavior.

--marcs