Ranando D Washington-King

Assuming a library author is willing to give up any semblance of the ergonomics that TC39 thought was so very important, it's possible to actually use private fields in a...

Yeesh. Why does everyone choose the hard approach? There's a 1 line fix to the above code to give @trusktr what he wants. ```js function Foo(Base) { return class Foo...

@ljharb Np. Thing is, I don't use mixins either. I tried them back in the early ES5 days, but grew to hate them quickly. What's more, the so-called "mixin" approach...

Think of the semantics. A "private" member is one that can only be accessed by its owner. If you "elevate" that from `class` scope to module scope, you've essentially just...

> I know about the approach you suggested, but that only work in that case. This doesn't: (example omitted) You do realize that you're asking 2 different classes to have...

>I would disagree, because this, {omitted} and {omitted} are not the same in terms of discoverability (the value in the first example can be discovered by external code, while this...

@trusktr When I say "private", I mean as defined by most languages that support the concept (not including ES which only finalized its acceptance a few days ago), which is...

How will you ever know? As is always the case, when bad decisions are made that don't completely break the language, they just end up in "the bad parts" lists,...

Thanks for the quick response. Hasn't that been faulty reasoning from the beginning? Every language supporting calculated members violates that notion unless the member is either private or overridden.

It just hit me. This is a problem of conflicting goals. Correct me if I'm wrong, but both of these appear to be goals for this proposal: * Any public,...