Summary: prototypes as classes (PaCs)

Brendan Eich brendan at mozilla.com
Tue Jun 28 17:32:20 PDT 2011


On Jun 28, 2011, at 5:30 PM, Axel Rauschmayer wrote:

>>> What do you do with constructors-as-classes to check the following?
>>>      o instanceof C
>>> You look for C.prototype in the prototype chain of o.
>> 
>> No, the JS engine does that!
>> 
>> I, or random classy-dynamic-language-experienced users, just do "o instanceof C", i.e., they ask "is o an instance of [constructed by] C"?
>> 
>> Not everyone mentally deconstructs operators into their more primitive semantics.
> 
> But with PaCs you don’t have to deconstruct, there is no detour from the class to another construct.

I just wrote that with classes or today's constructor functions, no one has to deconstruct, either.

On the other hand, having PaCs and classes/constructors is more complex than just having one. And we do not get the choice of just having PaCs.


>> Especially if there's no prototype-chain hacking, just shallow classical inheritance via a solid library.
> 
> 
> Then we would have a Python-like abstraction on top of current facilities. Which I don’t mind at all. But I’m worried about the abstraction leaking.

What leak? We want sugar for today's patterns. I think you keep assuming everyone thinks about prototypes not constructors, but that is not universally true -- far from it.

/be



More information about the es-discuss mailing list