> One last thing: how would you hope to deal with module-internal data stored on arbitrary objects, using any means other than private symbols or something similar?
Isn't this precisely what WeakMaps are for? If the data is "module-internal", then the module needs to be the owner of the data store. If the data is about "arbitrary objects" (object from outside the module?) then those objects are the keys to the data store. If any object is thrown away, the associated data is no longer needed. If this doesn't fit the functionality of a WeakMap, I don't know what will. > Weak maps make sense when the weak map is the dictionary conceptually (think: caching). Isn't that precisely what your question calls for? You're caching module-internal data about external objects. > Keep in mind, I'm specifically *against* the abuse of weak maps for private state that's conceptually (in an abstract sense, not runtime) part of an object. Likewise, I'm specifically against the abuse of objects to store state unrelated to the factory that created it. To me, that's as if I came to visit you and somehow you managed to hide some valuable info in my wallet without me noticing, and even if I completely dismantle my wallet, I wouldn't be able to find it. But somehow you can easily retrieve it the next time I come around. That's just conceptually weird. On Mon, Jul 30, 2018 at 9:42 PM Isiah Meadows <isiahmead...@gmail.com> wrote: > The reason private symbols are appropriate for Node's use case is > because it's conceptually a mixin, not a simple key/value map with > various utility functions (and weak map lookup is slower than property > access). JSDOM uses a similar utility [1] as a sort of mixin. > > Keep in mind, I'm specifically *against* the abuse of weak maps for > private state that's conceptually (in an abstract sense, not runtime) > part of an object. Weak maps make sense when the weak map is the > dictionary conceptually (think: caching). But if conceptually, the > object is the dictionary, putting it in a weak map is giving the > engine the wrong info - properties have inline caches and heavy > optimization, but you can't do the same for weak maps in the other > direction without literally implementing them as properties. (I would > *love* to be proven wrong here, BTW.) > > Let me draw a quick comparison: When do you use a map/set with string > keys, and when do you use an object instead? > > - Both are functionally equivalent, but engines use *very* different > algorithms for each one. > - I can almost guarantee you don't use maps when object properties work. > > One last thing: how would you hope to deal with module-internal data > stored on arbitrary objects, using any means other than private > symbols or something similar? To clarify, I'm talking of opaque object > structs [2], not simply classes. (BTW, that one is easier to manage as > a struct rather than a class, because of how many "methods" there are > operating on the state.) > > [1]: https://github.com/jsdom/js-symbol-tree > [2]: https://github.com/isiahmeadows/enigma/blob/master/src/parser.ts > > ----- > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > > On Mon, Jul 30, 2018 at 9:00 PM, Ranando King <king...@gmail.com> wrote: > > I meant to say if the object passed to the 3rd party function..... > > > > > > On Mon, Jul 30, 2018 at 7:59 PM Ranando King <king...@gmail.com> wrote: > >> > >> Just that use case alone is problematic. If the 3rd party function is > not > >> extensible, then the new private data should not be allowed. If the > library > >> cannot function without storing that data, then the function will have > no > >> choice but to fall back to WeakMaps which don't care if the key is not > >> extensible. So why not just stick with WeakMaps for that case? And if > that's > >> the case, then there would be little need for so open a means of > defining > >> private field names. The proposal I'm offering offers the room to > extend it > >> in the future to support everything else you might look for from your > >> private symbols idea.... unless you think I missed something. > >> > >> On Mon, Jul 30, 2018 at 7:26 PM Isiah Meadows <isiahmead...@gmail.com> > >> wrote: > >>> > >>> That is one supported use case, yes. But that isn't the only use case > >>> this supports. It can still extend to traditional private class data, > >>> too. > >>> > >>> ----- > >>> > >>> Isiah Meadows > >>> cont...@isiahmeadows.com > >>> www.isiahmeadows.com > >>> > >>> > >>> On Mon, Jul 30, 2018 at 8:04 PM, Ranando King <king...@gmail.com> > wrote: > >>> > So you're wanting the ability for a 3rd-party function to be able to > >>> > store > >>> > data private to that library on an object it didn't create, and that > >>> > only > >>> > that library can access? > >>> > > >>> > On Mon, Jul 30, 2018 at 6:36 PM Isiah Meadows < > isiahmead...@gmail.com> > >>> > wrote: > >>> >> > >>> >> First, my private symbols are properly *private*. The only > >>> >> "unexpected" thing that could happen is making an object larger > >>> >> memory-wise, which engines already have to be equipped to handle now > >>> >> (libraries aren't always well-behaved, and like to occasionally add > >>> >> expando properties to builtins and DOM elements). About the only > thing > >>> >> most people would care about is in the debugger. > >>> >> > >>> >> Second, I had things like this in mind with supporting expando > >>> >> properties: > >>> >> > >>> >> > https://github.com/nodejs/node/blob/ae4fde8bc883686def5badfb324236320669e8f4/lib/internal/linkedlist.js > >>> >> > >>> >> In that case, the Node.js people made it a pseudo-mixin rather than > an > >>> >> actual type for performance reasons - there's fewer object > allocations > >>> >> and they needed that. > >>> >> > >>> >> So I've considered the expando problem, and I disagree about it > being > >>> >> a problem at all. > >>> >> > >>> >> ----- > >>> >> > >>> >> Isiah Meadows > >>> >> cont...@isiahmeadows.com > >>> >> www.isiahmeadows.com > >>> >> > >>> >> > >>> >> On Mon, Jul 30, 2018 at 6:35 PM, Waldemar Horwat < > walde...@google.com> > >>> >> wrote: > >>> >> > On 07/29/2018 04:37 PM, Isiah Meadows wrote: > >>> >> >> > >>> >> >> BTW, I came up with an alternate proposal for privacy altogether: > >>> >> >> https://github.com/tc39/proposal-class-fields/issues/115 > >>> >> >> > >>> >> >> TL;DR: private symbols that proxies can't see and that can't be > >>> >> >> enumerated. > >>> >> > > >>> >> > > >>> >> > Aside from syntax, the main semantic difference I see between this > >>> >> > alternative and the main one is that this alternative defines > >>> >> > private > >>> >> > fields > >>> >> > as expandos, creating opportunities for mischief by attaching them > >>> >> > to > >>> >> > unexpected objects. Aside from privacy, one of the things the > >>> >> > private > >>> >> > fields proposal gives you is consistency among multiple private > >>> >> > fields > >>> >> > on > >>> >> > the same object. In the rare cases where you don't want that, you > >>> >> > could > >>> >> > use > >>> >> > weak maps. > >>> >> > > >>> >> > Waldemar > >>> >> _______________________________________________ > >>> >> es-discuss mailing list > >>> >> es-discuss@mozilla.org > >>> >> https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
