ECMAScript Object equivalence classes proposal

David Bruant david.bruant at
Sat Apr 2 11:44:21 PDT 2011


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 ( 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
var ElementProtoSibling = Object.create(null, {}, Element.prototype);
var EventTargetProtoSibling = Object.create(ElementProtoSibling, {},
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

If, instead of creating empty new objects, ElementProtoSibling and
EventTargetProtoSibling  were "own forwarding proxies" (concept
explained here: 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,

__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).


More information about the es-discuss mailing list