Prototypes as the new class declaration

Brendan Eich brendan at mozilla.com
Wed Jun 15 00:25:24 PDT 2011


On Jun 14, 2011, at 11:59 PM, Axel Rauschmayer wrote:

> Wouldn’t you add a class method like this?
> 
> const SkinnedMesh = THREE.Mesh <| {
>   cm: function() {
>   }
>   ...
> };
> 
> Then it could be invoked as SkinnedMesh.cm() (which to me is what a class method is: there is a class named SkinnedMesh and it has a method cm()).
> 
> Furthermore, it would automatically be inherited:
> 
> const SkinnedMeshExtended = SkinnedMesh <| { ... }
> 
> Then the following class method could also be called:
> 
> SkinnedMeshExtended.cm()
> 
> Right?

It has the right plurality -- I mean, the prototype is a singleton and so is the constructor.

You invoke it on the name of the abstraction, via dot -- check. Just like String.fromCharCode.

So let's go with that built-in: new String("hi") instanceof String is true, and same works for SkinnedMesh in both the classes proposal and Allen's class-free variant.

But String.fromCharCode is not inherited such that "hi".fromCharCode delegates to String.fromCharCode. Hrm.

I don't mean to single out String as a built-in. Whether user-defined or built-in, today's constructor functions can have "class properties" that are not inherited by instances. That seems like it could matter, e.g. to avoid having Object.keys suddenly make keys properties appear in all objects -- including in the global object!

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/9e49bdaa/attachment.html>


More information about the es-discuss mailing list