Class double-bind

Jason Orendorff jason.orendorff at gmail.com
Tue Mar 3 17:32:44 UTC 2015


On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> I didn't take the time to come up with a real example.  But code within a class body that refers to the containing class is something I have seem many times.  Some of the most common places you see this is in methods (instance or static) referring to "constants" defined as static properties of the class.  Another place you see it is "static" methods referring to other static methods of the same class or applying 'new' to their class name.  In most of these cases, there are actually better ways to do the same thing (referring to 'this' from within static methods, using 'this.constructor' within instance3 method) but many developer still use the direct name references.

Yes, we agree on all this. What's a bug is `Bar = { };`.

> Of course, using 'new this.construtor' internally would also break your logging wrapper.

The wrapper could be either a subclass (which will work inasmuch as a
subclass can substitute for the base class) or a proxy (which will
work inasmuch as a proxy can substitute for its target object). Or it
could just mutate the constructor link.

> Which brings us back to what should probably be the major point..  Class are supposed to be abstractions that encapsulate their internal implementation details.  Expecting that sort of wrapper to work an any sort of general situation is grossly violating that encapsulation.

Hmm. Usually the stronger an abstraction, the *better* wrapping works.
It's funny that it turns out not to work that way in this case.

To me, what's happening here is that the double-binding design is
just... weird. So unsurprisingly, it has weird consequences for users.
I don't think it even matters where one stands on the
classes-as-sugar/classes-as-abstraction spectrum.

-j


More information about the es-discuss mailing list