prototype focus

Tim Smart tim at fostle.com
Fri Jul 1 02:21:30 PDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110701/87ad5bcf/attachment-0001.html>


More information about the es-discuss mailing list