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
