A side thought: If a language reserving certain words, even to the point of generating error messages related to using them under certain circumstances, doesn't constitute at least part of a justification for using them, then why do languages so often reserve keywords for future use? Isn't precisely the case with `private`, `protected`, `public`, and `package` (and `class` prior to ES6). Weren't they all holdovers from the fact that the syntax for ES was mostly borrowed from Java, and kept in reserve just in case the concepts behind these keywords became language features?
If that's not the case, then there's no point in keeping these (or indeed any) keywords in reserve. On Fri, Aug 3, 2018 at 4:24 PM Ranando King <king...@gmail.com> wrote: > 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
