I'd argue that is 1:1 with the way subclasses work today. Protected properties can be implemented by sharing the weakmap instance with the parent.
Private properties can be implemented by using a unique weakmap instance for the subclass. I actually think it's pretty straightforward and simple. On Friday, August 3, 2018, Ranando King <[email protected]> wrote: > > 1. It's *super incredibly boilerplatey* and verbose syntactically. > > I'm not sure what you mean by "boilerplatey". As for being verbose, I'm > just using the keywords everyone understands for this purpose. IMO, there's > no advantage in trying to find some shorthand to do the same thing just > because it saves a keystroke or two when it makes the code significantly > more difficult to understand. > > > 2. `protected` on an object literal is next to useless. I've used that kind > of feature almost never. > > I get where you're coming from with that. I don't see it being used very > often (kinda like `with`), but it has to be there. If someone wants to use > the facilities of `class` without the limitations of the keyword, and the > intent is to build vertical hierarchies, they'll need the "protected" > keyword on their prototype definition to share private data with descendant > factories. It's even more necessary for people writing factory factories. > The only other way to achieve the same thing would be to force them to use > `Function()` or `eval` and build up the code as strings. I'd rather avoid > that. > > > I also find it odd you're supporting private dynamic properties. > > How'd you get to the idea that I'm supporting dynamic private properties? > The first 2 paragraphs in the implementation say that all private container > records are sealed, and all fields in info records are added read-only. If > it wasn't clear from that, I'm going to have to re-write that section. > However, the intent is that after the declaration process is complete, what > you have is all you can get. No additional private fields can be added > later. I considered dynamic private data, but that can get very messy very > quickly. > > > I actually think it's odd there is no attempt to implement dynamic > properties in the other "private properties" proposals. > > It's not that odd. There are issues around inheritance when a subclass can > remove the `protected` properties of its base. Further, exactly how do you > add a new `protected` property at runtime? Under both proposal-class-fields > and proposal-object-members, there is never any direct access to the > private container record, so use of `Object.defineProperty` will never > work. IMO, any attempt to implement dynamic private properties in any > sensible and consistent fashion would require somehow exposing the private > data record to the code. That's a recipe for a private data leak. Not worth > it. >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
