Some questions about Private Name Objects

Rick Waldron waldron.rick at
Fri Sep 14 13:50:05 PDT 2012

On Fri, Sep 14, 2012 at 12:58 PM, Kevin Smith <khs4473 at> wrote:

> 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?

I can't find any evidence that they were, however I did dig up evidence
that they were in fact accepted by everyone at the July 2011 meeting:

search that page for "private-name-alternatives.pdf"


> Kevin
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list