Some questions about Private Name Objects

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


On Fri, Sep 14, 2012 at 12:58 PM, Kevin Smith <khs4473 at gmail.com> 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:

https://mail.mozilla.org/pipermail/es-discuss/2011-August/016188.html

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



Rick



>
> Kevin
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120914/fe23776e/attachment.html>


More information about the es-discuss mailing list