An acceptable form of protected support

[rdking]

Following up on #178's debate regarding protected support.

@littledan said:

The problem is that you could make a subclass which reads the protected information, and then .call() this method on some other instance, so there is really no strong protection.

A few months ago, I created an example that shows it is possible to create protected data that does not allow thief sibling classes to be create. My question is whether or not this is sufficient to revive the argument for protected?

[mbrowne]

Thanks @rdking. I think it's worth mentioning that although I'm sure @rdking would prefer for protected members to be included in the current proposal, it should in theory be possible to add them later. I know many of us are experiencing fatigue with discussing anything about changing the current proposal at this point, but personally I'm more interested in discussing this with an eye toward future proposals—even if the best solution ultimately turns out to be a decorator, build-time solution, or something else.

[littledan]

This proposal is not going to add further features. I'd recommend pursuing this discussion in a separate proposal repository, or in TC39's new discourse instance.