Summary: prototypes as classes (PaCs)
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.
More information about the es-discuss