tc39 / proposal-static-class-features

The static parts of new class features, in a separate proposal
https://arai-a.github.io/ecma262-compare/?pr=1668
127 stars 27 forks source link

Add a quick note about use of private statics #33

Closed shicks closed 5 years ago

littledan commented 6 years ago

While this note is correct, I am not sure if it's the most clear place to put it. Don't we have this property explained in supporting documents already?

shicks commented 6 years ago

All I see is "This field is not installed on subclasses, and the initializer is only ever evaluated once", which is not particularly obvious without some parsing. There's the bit about not calling private static methods from subclasses, but I think that's an orthogonal issue. Given that the different possible decisions were discussed a few months ago as potential footguns (i.e. the current proposal vs variations where each subclass has its own separate slot, or where there's special handling so that all subclasses can somehow share a single slot), it seems reasonable to make it extra clear in the explainer exactly which decision was made, and how simply using the full class name basically skirts the problems with the other two options.

littledan commented 6 years ago

OK, more clarification seems like a good idea. However, in discussing this with people, the idea of "via a subclass" was hard to understand (many thought I was just saying it wasn't protected). I think this would be clearer with a code sample, rather than a one-line comment.

littledan commented 5 years ago

@shicks Do you have any plans to clarify the comment? Otherwise, I'll close this PR, as I think it would confuse more than clarify in its current form.

shicks commented 5 years ago

PTAL.

littledan commented 5 years ago

Thanks!

littledan commented 5 years ago

Thanks!