<div dir="ltr">Note that builtins with internal slots, like Map, Set, and Promise, are still mutable after being frozen - so if one is trying to model internal slots with some kind of property stored on the object, then freezing *must* have no effect on the ability to alter their contents.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 31, 2018 at 2:34 PM, Isiah Meadows <span dir="ltr"><<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you go back a few months, what you're proposing is *very* similar,<br>
at least functionally, to my previous iteration of my proposal:<br>
<a href="https://github.com/isiahmeadows/private-symbol-proposal/blob/c5c9781d9e76123c92d8fbc83681fdd3a9b0b319/README.md" rel="noreferrer" target="_blank">https://github.com/<wbr>isiahmeadows/private-symbol-<wbr>proposal/blob/<wbr>c5c9781d9e76123c92d8fbc83681fd<wbr>d3a9b0b319/README.md</a><br>
<br>
My main problem was that trying to limit private properties to objects<br>
created within a scope got complicated in a hurry once you considered<br>
all the small details, and it just didn't seem simple anymore. It only<br>
got more complicated when you started getting into the logistics of<br>
integrating with modules.<br>
<br>
So I've considered the issue and explored it pretty thoroughly - I<br>
*really* don't want private data to be limited to classes (which I<br>
dislike), but I did also previously have the concern of trying to<br>
limit who could define properties where.<br>
<br>
I will point out that you can prevent arbitrary private extension by<br>
simply doing `Object.preventExtensions(<wbr>object)`. Because properties<br>
defined using private symbols are otherwise just normal properties,<br>
they still have to go through the same access checks normal properties<br>
have to, like [[IsExtensible]]. The only other concrete difference is<br>
that proxy hooks don't fire when you do things with private symbols.<br>
<span class="im HOEnZb"><br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:contact@isiahmeadows.com">contact@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">On Tue, Jul 31, 2018 at 3:09 PM, Ranando King <<a href="mailto:kingmph@gmail.com">kingmph@gmail.com</a>> wrote:<br>
>> What use case are you referring to here?<br>
><br>
> In the case of SymbolTree, the objects in use are external.<br>
><br>
>> I think there’s been a misunderstanding. Everybody agrees that that’s a<br>
>> bad pattern. It’s not what the point of private symbols would be. It’s not a<br>
>> target use case.<br>
><br>
> That certainly puts my mind at ease.<br>
><br>
>> As Isiah said, “all of the examples here I've presented are for scenarios<br>
>> where the state is related to the factory that created the objects.”<br>
><br>
> If the factory that creates the objects is the also the only thing trying to<br>
> store private information on those objects, then I understand you're only<br>
> looking for per-instance module-private data, possibly with the ability to<br>
> use common private names. If that's the case, then it really is just 2<br>
> simple extensions of my proposal:<br>
> * allow a Symbol when used as a private or protected property name to<br>
> persist as the private Symbol name for the private instance field on each<br>
> object for which it is used.<br>
> * create an additional privilege level (internal) that places the new<br>
> field's name in the [[DeclarationInfo]] of the function containing the<br>
> declaration.<br>
><br>
> The effect of using these 2 features together is that anything within the<br>
> same function as the declared Symbol will gain access to the internal field<br>
> of all objects using that Symbol as a field name.<br>
><br>
> On Tue, Jul 31, 2018 at 1:36 PM Darien Valentine <<a href="mailto:valentinium@gmail.com">valentinium@gmail.com</a>><br>
> wrote:<br>
>><br>
>> > I'd say you've identified the common pattern, but that pattern itself is<br>
>> > a bad use case, and the use of private symbols as you have defined them<br>
>> > doesn't do anything to correct the technical issue.<br>
>><br>
>> I think there’s been a misunderstanding. Everybody agrees that that’s a<br>
>> bad pattern. It’s not what the point of private symbols would be. It’s not a<br>
>> target use case.<br>
>><br>
>> > Since you cannot stick new properties onto a non-extensible object, even<br>
>> > private symbols won't solve the problem with your use case.<br>
>><br>
>> That appending private symbols to external objects which are frozen<br>
>> wouldn’t work doesn’t matter precisely because it’s not a target use case.<br>
>> That it doesn’t work reliably might even be considered a positive, since it<br>
>> discourages something we all seem to agree is not good practice.<br>
>><br>
>> It’s also not related to private symbols; this is already how properties<br>
>> work, regardless of what kind of key they have.<br>
>><br>
>> > The difference here is that in your use cases, library A is "sneakily"<br>
>> > storing information on object B.<br>
>><br>
>> What use case are you referring to here? I can’t find any example in the<br>
>> previous posts that matches these descriptions. As Isiah said, “all of the<br>
>> examples here I've presented are for scenarios where the state is related to<br>
>> the factory that created the objects.” The same is true of my examples.<br>
>> Everybody’s on the same page regarding not wanting to add properties to<br>
>> objects their own libraries do not create.<br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
</div></div></blockquote></div><br></div>