Some questions about Private Name Objects

Kevin Smith khs4473 at gmail.com
Fri Sep 14 09:58:00 PDT 2012


>
> The real point I'm trying to make is that Name objects give us something
> akin to clojure's protocols. Imagine an "orm" protocol -- this is just a
> set of names that must exist on an object (or its proto chain). An object
> can implement any number of protocols (or interfaces, or whatever) without
> fear of conflict. You can easily override any implementation so long as you
> have a handle on the appropriate name object. This is easier, better
> looking and more correct than anything we can do today. It's not too
> disimilar from using using instanceof as a brand, but without the pitfalls
> (it doesn't fall flat crossing sandbox boundaries). This is a safe and
> flexible inheritance model that works just as a js programmer would expect,
> all without begging for mutable or multiple prototypes.
>

I think this is a winning argument.  So the problem becomes: how can we
implement this in a non-fugly way?  As it stands (and as Allen has pointed
out), we don't currently have the syntax to make this work, even for
"iterator":

    import iterator from "sys:iterator"; // Sorry, hate @'s : )

    class Derived extends Base {

      // Hmmm... No way to put iterator here.
    }

    // Try here?  Fugly...
    X.prototype[iterator] = function() {

      super.doSomething(); // Oops - super outside of class definition : (
    };

The absolute minimum we need is a way to specify computed property names in
classes (and what the heck, object literals too):

    import iterator from "sys:iterator";

    class Derived extends Base {

      [iterator]() {
        super.doSomething(); // Works like a charm!
      }
    }

This is IMO the best way forward.  It's generally useful beyond the use
case presented here and does not use up a valuable free ASCII character.
 It also doesn't require any new symbolism since we already understand that
brackets indicate computed property names.  Why were computed property
names killed again?

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120914/4909e852/attachment-0001.html>


More information about the es-discuss mailing list