On Oct 31, 2011, at 10:45 AM, John J Barton wrote: > On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich <bren...@mozilla.com> 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss