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
