inheritance in E
Jonathan S. Shapiro
Mon, 26 Oct 1998 10:18:12 -0500
> On markm's behalf, I am terrified of things that will put people
I still wonder how the VB question should impact our view. The
members of this list (myself included) are heavily centered around
Perl and Python, and I am concerned that this may lend itself to a
mis-biased predisposition about the importance of inheritance.
At this point I am not trying to argue for a particular position.
Rather, I am trying to outline my perception of the state of the world
and the tradeoffs among choices in case that is useful. [Actually, I
found as I wrote this out that my market instincts went in the
pro-inheritance direction in spite of the fact that it makes my
technical instincts cringe.]
First, I believe that *from the perspective of language feature
comparison* Java and C++ can be ruled out for comparison on grounds
that they simply aren't scripting languages (at all).
Java, however, must be considered on another basis: E has a defined
binding to Java. It may be that supporting this binding
*necessitates* an inheritance model within E. If this is the case,
then I suggest that we have arrived at a technical criterion that
obviates the rest of the discussion. Can MarkM clarify on this issue?
In examining the Perl/Python/VB spectrum, I think we must ask what
audience we intend to reach in order to determine what expectations
exist. I see three particularly useful possibilities in the spectrum
of users (note that they are not intended to be mutually exclusive):
1. We are trying to reach the great unwashed (the millions of
users scenario). These people may be assumed to be VB users
to the extent that they use anything.
2. We are initially trying to reach the subset of people who
develop web sites for such end users. These people divide
into two camps along approximately even lines:
a) IIS developers, who are most accustomed to VB-based
b) Apache et. al. developers, who seem to use Perl mostly,
but many of whom are knowledgeable about Python and Java
To the extent that Java servlets succeed in coming into vogue,
we might wish also to take a looking ahead view and begin to
consider that Java is becoming a scripting language after all.
3. We are trying to gain the attention of high-end developers who
support the Fortune 500 world. MarkM certainly has not
focused on these as a primary audience, but I believe he may
now feel that reaching these people offers considerable
leverage if it can be done without compromising the first two
I personally believe that we should examine only groups (2) and (3),
as group (1) doesn't write scripts except as a matter of last resort,
and then only in Excel. :-)
As a technical aside, I'ld note that VB does not seem to suffer as a
scripting language from it's lack of inheritance, but this is in part
because a lot of ``object nature'' has been embedded in the
environment in ways that VB programmers never realize is happening.
It doesn't have inheritance, but it does have a loose notion of object
embedded in the runtime environment and a notion of object-based event
Possible pruning questions:
1. Do we anticipate that E will be used to do event capture and
handling in the style that is common in Win32 controls? If so,
then I believe it requires some sort of object nature. The issue
is that most of the event dispatch systems dispatch the events to
some object type that is close to the root of the type hierarchy,
which in turn passes the event *down* the inheritance tree toward
Event routing in such models is closely related to the inheritance
The MFC classes, for all that I gripe about them sometimes, do
quite a decently engineered job with all of this.
2. What about the language binding question? Does that just put an
end to the debate?
3. To the extent that the current market PR forces will cause Java
servelets to penetrate, does this become a leverageable trend that
argues for language similarity? Might it even argue for removing
the VB-style syntax? [My observation is that parsers are hard to
maintain, and multiple syntax options will make them much *harder*
4. Given that inheritance is already in, is our time best spent on
building a runtime system that doesn't rely on inheritance, or is
it best spent on other issues like building exemplars?
Some things that I feel might greatly help E's penetration:
a) exemplar mini-applications
b) explanatory/tutorial examples
c) library of useful components (I haven't looked enough to know
if this may already be there).
5. Who will actually adopt early? My personal belief is that the IIS
folks will be slow to adopt E no matter what, so early success lies
with the Java/Perl/Python crowd. This crowd is familiar with
inheritance. Should we just give them what they expect?