> The argument I raised with Isiah was just 1 example of a bad pattern that > being too generic can open up.
BTW, the risk for bad patterns doesn't necessarily justify exclusion of a feature. As I've brought up here before, iterators can be seriously abused similarly [1], thanks to the availability of `throw` + `return`, and you can always make a deferred out of a promise by simply pulling the `resolve`/`reject` out of the promise callback's scope. As long as it looks strange and weird enough and we have more semantically appropriate alternatives, I don't think we have an issue with potential abuse, and I feel private symbols as I have them meet this threshold. [1]: https://github.com/tc39/proposal-async-iteration/issues/68 ----- Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Tue, Jul 31, 2018 at 5:10 PM, Ranando King <king...@gmail.com> wrote: > I get where you're coming from. The main reasons I've written my proposal > this way are: > > * Prior art: > - Many ES developers come from other, class-based, object-oriented > languages where keywords are the primary way of controlling data > accessibility. This means using the well known keywords will lower the > learning curve and increase adoption. > * Future expansion: > - Careful and narrow definition of the keywords and their corresponding > actions allows undesirable patterns to be avoided while leaving room for > future extensibility. > > The argument I raised with Isiah was just 1 example of a bad pattern that > being too generic can open up. These are also part of the reasons why I am > against proposal-class-fields. It seems so simple on the surface, but > effectively makes an already limited keyword even more limited than is > should be. Plus it adds difficulty to creating new features around those > concepts in a way that will be easily understood by developers migrating > from other languages. > > > On Tue, Jul 31, 2018 at 3:43 PM Darien Valentine <valentin...@gmail.com> > wrote: >> >> You’re right, sorry — the SymbolTree example does operate on objects not >> created in the module itself, so my statement wasn’t accurate. >> >> More carefully I ought to have said that the use cases concern object >> creation. Decorators and mixin functionality can fall in this bucket, where >> the object is likely not literally “birthed” by the library that is doing >> the decorating, yet the functionality is intended to be attached during that >> process by a consumer of the library. >> >> In my own experience to date, all cases where I have run into the >> class-declaration scope limitation did concern locally created objects >> (class instances specifically), so yes, the adjustments you are talking >> about wrt the object members proposal probably would be able to cover them, >> though I would still tend to favor a more generic and simple solution. >> >> 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
