Good argument. However, the fact that the wide adoption `private` and `public` in other languages constitutes an immediately understood, well-recognized syntax for declaring privilege levels in languages with classes is my primary reason for adopting those already reserved keywords. The fact that I also think it would be a waste not to use them is just a personal bias I'm willing to disregard in the face of a good, sound, logical reason for not using them.
On Fri, Aug 3, 2018 at 4:07 PM Jordan Harband <ljh...@gmail.com> wrote: > 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 <isiahmead...@gmail.com> > 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 >> cont...@isiahmeadows.com >> www.isiahmeadows.com >> >> >> On Fri, Aug 3, 2018 at 8:34 AM, Michael Theriot >> <michael.lee.ther...@gmail.com> 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 <isiahmead...@gmail.com> >> 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 >> >> cont...@isiahmeadows.com >> >> www.isiahmeadows.com >> >> >> >> >> >> On Wed, Aug 1, 2018 at 11:54 PM, Ranando King <king...@gmail.com> >> wrote: >> >> > >> https://github.com/rdking/proposal-object-members/blob/master/README.md >> >> > >> >> > On Wed, Aug 1, 2018 at 2:01 AM Isiah Meadows <isiahmead...@gmail.com >> > >> >> > 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 >> >> >> cont...@isiahmeadows.com >> >> >> www.isiahmeadows.com >> >> >> >> >> >> >> >> >> On Wed, Aug 1, 2018 at 2:18 AM, Ranando King <king...@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: >> >> >> > >> >> >> > 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 >> >> >> > <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 >> > > _______________________________________________ > 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
