A keyword being reserved is NOT the same as "being a part of ES". `package` is reserved too, but there's zero concept of packages in the language, and absolutely no obligation for there ever to be one.
To reiterate, the existence of `private`, `public`, and `protected` as reserved keywords in *no way* justifies including any, or all, of these keywords in any language feature. On Fri, Aug 3, 2018 at 12:36 PM, Isiah Meadows <[email protected]> wrote: > My "private symbols" proposal supports it, but that's about it. > > I think the main thing is that the use case isn't really that large, > so nobody's really thought about it. (You can always "pretend" it > exists by creating a single private key that's just an object > dictionary.) > ----- > > Isiah Meadows > [email protected] > www.isiahmeadows.com > > > On Fri, Aug 3, 2018 at 8:34 AM, Michael Theriot > <[email protected]> wrote: > > If I understand the terminology, "private dynamic properties" are easily > > polyfilled via weakmaps? > > > > I actually think it's odd there is no attempt to implement dynamic > > properties in the other "private properties" proposals. > > > > > > On Friday, August 3, 2018, Isiah Meadows <[email protected]> wrote: > >> > >> Okay, now that I look at that proposal, I see two issues right off: > >> > >> 1. It's *super incredibly boilerplatey* and verbose syntactically. I > >> don't know very many people who'd be willing to downgrade very far > >> from even what TypeScript has. (I'm specifically referring to the > >> declarations here.) > >> 2. `protected` on an object literal is next to useless. I've used that > >> kind of feature almost never. > >> > >> I also find it odd you're supporting private dynamic properties. It > >> does make polyfilling next to impossible, though. > >> > >> Just my 2 cents on it. (I glanced over this while very tired, so I > >> probably missed several highlights. These are what stuck out to me.) > >> > >> ----- > >> > >> Isiah Meadows > >> [email protected] > >> www.isiahmeadows.com > >> > >> > >> On Wed, Aug 1, 2018 at 11:54 PM, Ranando King <[email protected]> > wrote: > >> > 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 > _______________________________________________ > 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
