Yeah, I left it without saying that you could just model them as having their state as a single private symbol field with all the relevant data for it. I assumed it would be obvious enough for those who really pay attention to the spec, so I just left it implied. -----
Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Tue, Jul 31, 2018 at 5:40 PM, Jordan Harband <ljh...@gmail.com> wrote: > 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 <isiahmead...@gmail.com> > 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 >> cont...@isiahmeadows.com >> www.isiahmeadows.com >> >> >> On Tue, Jul 31, 2018 at 3:09 PM, Ranando King <king...@gmail.com> 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 <valentin...@gmail.com> >> > 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 >> 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
