<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018 at 7:26 PM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That is one supported use case, yes. But that isn't the only use case<br>
this supports. It can still extend to traditional private class data,<br>
too.<br>
<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
<br>
On Mon, Jul 30, 2018 at 8:04 PM, Ranando King <<a href="mailto:kingmph@gmail.com" target="_blank">kingmph@gmail.com</a>> wrote:<br>
> So you're wanting the ability for a 3rd-party function to be able to store<br>
> data private to that library on an object it didn't create, and that only<br>
> that library can access?<br>
><br>
> On Mon, Jul 30, 2018 at 6:36 PM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>><br>
> wrote:<br>
>><br>
>> First, my private symbols are properly *private*. The only<br>
>> "unexpected" thing that could happen is making an object larger<br>
>> memory-wise, which engines already have to be equipped to handle now<br>
>> (libraries aren't always well-behaved, and like to occasionally add<br>
>> expando properties to builtins and DOM elements). About the only thing<br>
>> most people would care about is in the debugger.<br>
>><br>
>> Second, I had things like this in mind with supporting expando<br>
>> properties:<br>
>> <a href="https://github.com/nodejs/node/blob/ae4fde8bc883686def5badfb324236320669e8f4/lib/internal/linkedlist.js" rel="noreferrer" target="_blank">https://github.com/nodejs/node/blob/ae4fde8bc883686def5badfb324236320669e8f4/lib/internal/linkedlist.js</a><br>
>><br>
>> In that case, the Node.js people made it a pseudo-mixin rather than an<br>
>> actual type for performance reasons - there's fewer object allocations<br>
>> and they needed that.<br>
>><br>
>> So I've considered the expando problem, and I disagree about it being<br>
>> a problem at all.<br>
>><br>
>> -----<br>
>><br>
>> Isiah Meadows<br>
>> <a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br>
>> <a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
>><br>
>><br>
>> On Mon, Jul 30, 2018 at 6:35 PM, Waldemar Horwat <<a href="mailto:waldemar@google.com" target="_blank">waldemar@google.com</a>><br>
>> wrote:<br>
>> > On 07/29/2018 04:37 PM, Isiah Meadows wrote:<br>
>> >><br>
>> >> BTW, I came up with an alternate proposal for privacy altogether:<br>
>> >> <a href="https://github.com/tc39/proposal-class-fields/issues/115" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-class-fields/issues/115</a><br>
>> >><br>
>> >> TL;DR: private symbols that proxies can't see and that can't be<br>
>> >> enumerated.<br>
>> ><br>
>> ><br>
>> > Aside from syntax, the main semantic difference I see between this<br>
>> > alternative and the main one is that this alternative defines private<br>
>> > fields<br>
>> > as expandos, creating opportunities for mischief by attaching them to<br>
>> > unexpected objects.  Aside from privacy, one of the things the private<br>
>> > fields proposal gives you is consistency among multiple private fields<br>
>> > on<br>
>> > the same object.  In the rare cases where you don't want that, you could<br>
>> > use<br>
>> > weak maps.<br>
>> ><br>
>> >     Waldemar<br>
>> _______________________________________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>