On Oct 31, 2011, at 10:45 AM, John J Barton wrote:
> On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich <[email protected]> wrote:
>> On Oct 31, 2011, at 9:45 AM, John J Barton wrote:
>>
>>> In my opinion for new syntax to support classical inheritance should 1)
>>> target beginners and 2) help avoid the need for F.prototype/new F() pattern
>>> for simple inheritance.
>>
>> John, I almost-completely agree with you (yay!), except for the |new F|
>> objection. What's wrong with operator new for class instantiation?
...
> In class languages I say:
> class F something E withOverrides {}
...
>
> Immediately after this phase the class-based language pattern leads
> you to think you are accomplishing great things, but mostly you are
> focusing premature on abstraction details. But that critical phase
> from "given an object |E|" to declaring |F| provides a big advantage.
> I believe this is why devs gravitate to selfish and extends() models.
John,
I'm going to circle back to some of your other points in another message, but
first I want to address your final point.
You start in the 9:45 AM message talking about making classical inheritance
simple. However, in the final sentence you mention selfish and extends() as
the things that devs gravitate towards as a solution to that problem. But
those are both (more or less) prototypal inheritance based designs. They
aren't doing classical inheritance.
We have talked quite a bit about how we could support very simple expression of
prototypal inheritance that is very close to the ideal you seem to be looking
for:
let E = {...} //E is just some object
let F = E <| { //bikesheding <| is a separate topic
method1() {},
method2() {},
//etc.
};
var f = new F;
but if you want to have instance initialization behavior you would define it
like:
let F2 = E <| {
method1() {},
method2() {}, //overrides
constructor(init) {
this.x = init;
}
};
var f2 = new F2(42);
We have recently taken to calling this pattern "object exemplars". It is
prototypal inheritance, almost exactly equivalent to what selfish does. If we
could all be satisfied with this there would be no need for the ongoing debate.
However, some people do not seem to be satisfied.
Fundamentally, what we are trying to enable here is the simple creation of
named abstractions over sets of behaviorally related objects. This is important
became it allows devs to think and communicate about the set rather than the
individual objects. The complication comes when we must decide what sort of
runtime entity is actually assigned a name. In selfish and in the above
examples it is a regular object that is named. This object is considered to be
a "prototype" because it provides the prototypical behavior that is shared by
all members of the abstraction. This is what is going on in my above examples
even though the word "prototype" never explicitly appears.
The objection that is raised is that we are assigning the name to the wrong
kind of object. The original JavaScript approach to creating objects uses a
separately defined constructor function and it is the function that is given a
name. When you say new Array() in JS you are not referring to the prototypal
array object, instead you are referring to a function that creates arrays and
implicitly associates they with Array.prototype. Some would go as far to say
that named constructor functions are how JS manifests classes -- the
constructor functions are the class objects. Their objection to the object
exemplar pattern is that it isn't really how JS does classes.
Sometimes it sounds like what you are asking for is precisely what objects
exemplars provide. But other times you say you want "classical inheritance".
Which is it?
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
