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?
I don't object to "operator new" for creating instances. (It is more
wordy in definition than a function property "new", a minor point).
My objection is the specification of methods on the |.prototype|
property of the right-hand side operand of "operator new". I
understand that it makes some logical sense, but we also know that
it's confusing to even experienced developers. We can't take it back.
Can we make it's use less important? Can we avoid using this odd
relationship in future features?
We could try to analyze why the F.prototype/new F() pattern is
confusing. I think the pattern is confusing when you start where
developers start. Given an object |E|, I want to create objects with
the methods of |E| except from an override. My goals is:
let f = new F(); // F is like E but different.
So I must define F in terms of E.
In class languages I say:
class F something E withOverrides {}
In JavaScript I have to stop and think about |.prototype|. I want to
concentrate on |E| and the overrides, but instead I am re-reading
Crockford.
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.
jjb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
