domenic at domenicdenicola.com (2013-10-13T02:36:46.706Z)
On Thu, Sep 26, 2013 at 7:14 PM, David Herman <dherman at mozilla.com> wrote:
> So let's assume there is such a registry. You can avoid accidental
> collisions with the ugliest name in the universe -- gensym that thing to
> the n'th degree -- but you're no longer forcing all clients to deal with
> the ugliness. You've abstracted it behind your library. Let's say I'm
> implementing a serialization library and want to create a @@serialize
> symbol for people to coordinate on. I'd do something like the following:
>
> // serialize.js
> import { lookup, register } from "js/registry";
>
> const myGUID = "__@@blaaaaarrrgggghhhAAAAAUUUUUGGGGHHHfnordfnordfnord29834983413451839512@@__";
>
Thinking about this in terms of tooling, at even the terminal level, might
look like this: ![{ '__@@blaaaaarrrgggghhhAAAAAUUUUUGGGGHHHfnordfnordfnord29834983413451839512@@__': [Function, '[symbol]': [Function] }](http://gyazo.com/f61d0e25366ce7e526c79ab7fa77cb17.png)
Subjectively, this makes my skin crawl.
On Thu, Sep 26, 2013 at 7:14 PM, David Herman <dherman at mozilla.com> wrote: > So let's assume there is such a registry. You can avoid accidental > collisions with the ugliest name in the universe -- gensym that thing to > the n'th degree -- but you're no longer forcing all clients to deal with > the ugliness. You've abstracted it behind your library. Let's say I'm > implementing a serialization library and want to create a @@serialize > symbol for people to coordinate on. I'd do something like the following: > > // serialize.js > import { lookup, register } from "js/registry"; > > const myGUID = > "__@@blaaaaarrrgggghhhAAAAAUUUUUGGGGHHHfnordfnordfnord29834983413451839512@ > @__"; > Thinking about this in terms of tooling, at even the terminal level, might look like this: http://gyazo.com/f61d0e25366ce7e526c79ab7fa77cb17.png Subjectively, this makes my skin crawl. Rick > > export default = lookup(myGUID) || register(myGUID, new > Symbol("friendly name")); > > Now every client simply gets to use > > import serialize from "serialize"; > > obj[serialize] = function() { ... }; > > without having to care about how ugly the GUID used in the registry was. > > Dave > > On Sep 26, 2013, at 4:07 PM, "Mark S. Miller" <erights at google.com> wrote: > > > I think we swept the collision problem under the registry rug. Let's > start by discussing registry designs assuming we do have Symbols. Let's see > if we can design a registry that allows cross-realm duck typing without > re-introducing the same possibility of accidental collision that we'd have > without Symbols. Note: For this question, malicious collision is not an > issue. > > > > > > On Thu, Sep 26, 2013 at 4:02 PM, Rick Waldron <waldron.rick at gmail.com> > wrote: > > > > > > > > On Thu, Sep 26, 2013 at 6:51 PM, Domenic Denicola < > domenic at domenicdenicola.com> wrote: > > > > > > > On Sep 26, 2013, at 18:49, "Yehuda Katz" <wycats at gmail.com> wrote: > > > > > > Private state doesn't satisfy these requirements because they trap on > the wrong side of the proxy. > > > > Agreed, in many cases I don't want private state; I *want* something > that can be copied by Object.mixin, for example. For private state, weak > maps are fine, and used today already. > > > > > > Agreed with Yehuda and both of Domenic's points. I don't need/want > Symbol for private anything—I want it for cases that don't deserve a > WeakMap, should be reflected and can be "seen" by > Object.getOwnPropertySymbols(), but want to avoid the possibility of > collision. > > > > Rick > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss at mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > > -- > > Cheers, > > --MarkM > > _______________________________________________ > > 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/20130926/616adf9c/attachment.html>