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