From: Boris Zbarsky [mailto:[email protected]]
> I think it depends on what the "internal properties" bit is and how flexible > it's supposed to be. > For example, if in this case the basic operation would be to check for a C++ > Element instance and then call some C++ method with that instance, that's > pretty optimizable. But if it's something that can be varied independently > of being an Element, then it's not so easy to optimize. Hmm, the issue is, this internal-properties thing is pretty prevalent in ES6 generally. All the built-ins can now be subclassed, and the mechanism in the spec for that is by giving them internal data properties that are initialized by their @@create, so that subclasses get those data properties too. I imagine whatever trick you guys are going to use for ensuring arrays, dates, etc. maintain their current performance in the face of this new spec mechanism can also be applied to `Element`s? One thing that might help (but IANAImplementer! :P) is that `Array`, `Date`, etc. don't give you the ability to arbitrarily brand other objects as arrays, dates, etc. They just give you `Array[@@create]()`, `Date[@@create]()`, etc. for *creating* such branded objects. The same could presumably work for `Element`s?
