!Re: proposal: Object Members
michael.lee.theriot at gmail.com
Fri Aug 3 16:37:59 UTC 2018
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 <kingmph at 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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss