Summary: prototypes as classes (PaCs)

Brendan Eich brendan at
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.


More information about the es-discuss mailing list