Editorial: Phrase private methods as brands, not fields

[littledan]

Many people attempting to implement private methods, both in transpilers and native JS engines, have run into similar sources of confusion about semantics and optimizability:

• Many have the misconception that each instance of a class with private methods has its own copy of that method, as if it were written in a field initializer, when actually, the same function identity is intended.
• Private methods are designed to have semantics that they can be implemented as a single check that the receiver "has" the private method, followed by a call of that method, without taking up memory space per-instance. However, many implementers are reaching for a direct implementation of them as non-writable private fields, which ends up taking a large amount of additional space.

To clear things up, this patch rephrases private methods and accessors' semantics as being based on a brand check, followed by a function call. Each object has a list of "private brands" it supports, which are identified by Klass.prototype, for classes Klass which have private methods or accessors. Private names are considered to have both a reference to this brand as well as the actual method linked from them. My hope is that this will be a reasonable first-pass implementation strategy; there is a note about how to optimize the brand list further.

With this change, the static class features needs some simple changes, and the decorators proposal needs some larger changes. See https://github.com/tc39/proposal-decorators/issues/180 for details.

[littledan]

OK, I'm going to land this patch so it's more easy to read this version. If anyone has concerns with it, please say so here, and I can roll it back.