https://github.com/rdking/proposal-object-members/blob/master/README.md
On Wed, Aug 1, 2018 at 2:01 AM Isiah Meadows <[email protected]> wrote: > Do you have a link to this proposal so I can take a look at it? It'd > be much easier to critique it if I could see the proposal text. > ----- > > Isiah Meadows > [email protected] > www.isiahmeadows.com > > > On Wed, Aug 1, 2018 at 2:18 AM, Ranando King <[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: > > > > That functional similarity is intentional. After pouring over years > worth of > > posts, I figured out what the vast majority of the proposal-class-fields > > detractors actually wanted: an elegant, easily recognized syntax for > adding > > private members to objects. > > > >> 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. > > > > I noticed that about your proposal too. I'm also pretty sure that Daniel > E. > > and Kevin G. ran into the same issues back during the > proposal-private-names > > days which is why the private names concept is just an implementation > detail > > in their current proposal. My proposal is made less complicated by > breaking > > the problem down into the 3 pieces required to make it all work: > > 1. a record to store private data > > 2. an array to hold references to the schema records of accessible > private > > data > > 3. a schema record for the sharable data. > > > > In this way private = encapsulated on a non-function, protected = > private + > > shared, and static = encapsulated on a function. It should be easy to > sort > > out how the data would be stored given such simple definitions. These > simple > > definitions also mean that encapsulation is naturally confined to > > definitions. Attempts to alter that state lead to strange logical > > contradictions and potential leaks of encapsulated data. I have thought > of > > the possibility that private data could be added after definition, but > every > > attempt I make to consider such a thing has so far led to a risk of > leaking. > > > > I've been working on some code that can serve as a proof-of-concept in > ES6. > > It will implement all of my proposal that can reasonably be implemented > in > > ES6 using Proxy. It's already in the proposal repository under the POC > > branch, but it's still a WIP. For now, it already supports inheriting > from > > native objects. I'm working on subclassing right now. By the time I get > done > > (likely this coming Monday), it should support every feature in my > proposal. > > I'm basically using it as a means to check the viability of my proposal. > > > > On Tue, Jul 31, 2018 at 4:35 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
