I'm glad someone other than myself can appreciate it. I trudged my way through a lot of variations on the theme to find the implementation that would make the most sense and still behave properly. It really is rather simple. The POC will more or less show how it can be implemented. The only issue I'm having at the moment is trying to capture access to `super` properties. Apparently V8 doesn't redirect `super` through prototypes like I was expecting, so I'm beginning to think that I won't be able to implement calls to protected methods of the base in this POC.
On Fri, Aug 3, 2018 at 11:38 AM Michael Theriot < michael.lee.ther...@gmail.com> wrote: > 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 <king...@gmail.com> 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
