Hi, This proposal is another attempt to address the DOM Element+EventTarget multiple inheritance issue in ECMAScript.
The main idea of my proposal is to introduce the concept of "object equivalence classes". First off, I'd like to say that I refer to a concept (http://en.wikipedia.org/wiki/Equivalence_class) which has nothing to do whatsoever with "classes" understood in a programming language inheritance context. The idea is to turn the == operator into an equivalence relation operator. The careful reader will instantly notice that actually, it already is (even if not explicitly stated in the spec). But the equivalence classes only contain one element each. So, the actual idea is to provide a mecanism to add new objects in an existing equivalence class. Each object would then have: - An identity (discriminable with ===) - An equivalence class (discriminable with ==) For the same reason Proxies shouldn't be able to redefine behavior of existing objects, the mechanism I'd like to introduce should not be able to change the equivalence class of an existing object. So, for the rest of this message, I'll expand my equivalence classes doing the following: --- // Assuming o is an object already in the environment var o2 = Object.create(null, {}, o); // third argument is an object // The newly created object and o will be in the same equivalence class // If the third argument is omitted, the new object belongs to a new equivalence class. --- We have: - o2 == o - o2 !== o - For all object a: o2 == a iff o == a (by transitivity by is in the definition of an equivalence class) __Implementing Element+EventTarget multiple inheritance__ Some properties we'd like to consider solving the problem. We'd like an object o such that: - o instanceof Element === true - o instanceof EventTarget === true - The built-in Element.prototype object is NOT in the built-in EventTarget prototype chain and vice versa Imagining that "instanceof", was checking for object equivalence (==) (instead of same object reference, ===), then we could do the following (siblinghood is used as a metaphor for belonging in the same equivalence class): --- var ElementProtoSibling = Object.create(null, {}, Element.prototype); var EventTargetProtoSibling = Object.create(ElementProtoSibling, {}, EventTarget.prototype); var e = Object.create(EventTargetProtoSibling, {}); --- We have: - e instanceof Element === true - e instanceof EventTarget === true These stand because instanceof would test equivalence instead of strict equality If, instead of creating empty new objects, ElementProtoSibling and EventTargetProtoSibling were "own forwarding proxies" (concept explained here: https://mail.mozilla.org/pipermail/es-discuss/2011-March/013361.html) to respectively Element.prototype and EventTarget.prototype, then e would inherit from these objects the way we expect it to. (Of course, some notation would need to be introduce so that proxies can be added to an existing equivalence class. Proxy.create(handler, proto, eqClassObject)?) __Backward compatibility issues__ None for pure ECMAScript programs (since, as said, equivalence classes already exists but only contain one element by construction). There are going to be issues if current code using the DOM tests non-strict equality (==) after calls to Object.getPrototypeOf. But since DOM prototypes are the mess we're trying to get standardized in WebIDL, it may not be that big of a deal. __Implementation considerations__ This proposal affects Object initialisation and == testing. I don't see big issues in implementing equivalence classes in both time and space for these aspects. __Relationship to other parts of the spec__ If this proposal was considered, it might be worth checking all places in the spec where there is a strict comparison (same reference). Maybe that these tests could benefit from the definition of equivalence classes instead like instanceof do (as I propose). David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
