prototype focus

Axel Rauschmayer axel at rauschma.de
Fri Jul 1 03:00:04 PDT 2011


BTW: I like the :: proposal (Brendan will remind you that it’s already taken, though...).
What you are in fact creating is the illusion that the class name refers to the prototype (with PAC, the :: would turn into a dot).

On Jul 1, 2011, at 11:21 , Tim Smart wrote:

> I quite the current prototype model we have in ecma5. My only gripes would be that `prototype` to too wordy, and `__proto__` needs to become standard. If you replaced `prototype` with `::` or something everything would be swell.
> 
> function Parent (name) {
>   this.name = name || this.constructor.DEFAULT_NAME
> }
> Parent.DEFAULT_NAME = 'bob'
> 
> function Child (name, age) {
>   Parent.call(this, name)
>   this.age = age
> }
> Child.__proto__ = Parent
> Child::__proto__ = Parent.prototype
> Child::describe = function () {
>   return 'I am called ' + this.name + ' and I am ' + this.age + ' years old'
> }
> 
> Tim.
> 
> On 1 July 2011 21:10, Axel Rauschmayer <axel at rauschma.de> wrote:
> > I don't think
> > JavaScript has ever been far from its prototype roots especially if
> > the programmer shifts to thinking about a prototype object instead of
> > thinking about a functions prototype property.
> 
> That is basically the point that the proposal tries to make. Have you taken a look at the library code? It is very short and not a radical overhaul.
> http://dl.2ality.com/dl/2011/06/Proto.js
> 
> Note how below, there is always an extra "prototype" in there with constructor functions.
> 
> Super-calls (there will be syntactic sugar for this):
> - Constructor functions: Superclass.prototype.foo.call(this)
> - PAC: Superclass.foo.call(this)
> 
> Subclassing:
> - Constructor functions: Subclass.prototype = Object.create(Superclass.prototype)
> - PAC: let Subclass = Object.create(Superclass)
> 
> Instanceof (internally):
> - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
> - PAC: o instanceof C === C.isPrototypeOf(o)
> 
> 
> >> Problems that both prototypes-as-classes (PAC) and class literals (CL) are
> >> trying to solve are:
> >> - Subclassing is hard and not directly supported by the language: connecting
> >> prototypes, chaining constructors, super-references.
> >
> > Object.getPrototypeOf(this).foo.call(this) is pretty long.
> 
> See above.
> 
> > It seems to me that perhaps the PaC drifted too far or perhaps started
> > too far from what JavaScript has already. If the idea is to shift the
> > focus more towards prototypes, then starting from something like what
> > I've written and adding "super" syntax would be more consistent with
> > what JavaScript already has.
> 
> 
> “too far from what JavaScript has already” is very vague. How so? With class literals, your code will look like PAC, anyway. Have you taken a look at Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
> http://www.2ality.com/2011/06/prototypes-as-classes.html#3
> 
> I find Brendan’s anti-PAC argument much more convincing: that all people might find it more natural to think in terms of constructors than in terms of prototypes. If that is the case then PAC would be a bad idea. The other convincing anti-PAC argument is that it is a bad idea to have two class mechanisms.
> 
> --
> Dr. Axel Rauschmayer
> 
> axel at rauschma.de
> twitter.com/rauschma
> 
> home: rauschma.de
> blog: 2ality.com
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

-- 
Dr. Axel Rauschmayer

axel at rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110701/bcc01e4d/attachment-0001.html>


More information about the es-discuss mailing list