That is a very useful document. I guess I haven't opened the proposal in a while.
He puts a lot of stress on preserving encapsulation where as I was planning on relying on a type system to optionally provide that feature. That is given a dynamically typed variable accessing privates would probably be allowed. (Statically typed variables would detect and not allow that kind of like a more strict usage). I think the inheritance and using private names as keys are decent arguments. That said I'm personally not against allowing inherited classes access to their base class private members though. That is private acting like protected in C++ I think is fine for ECMAScript. Am I alone in being fine with that behavior? I'm kind of leaning toward: https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883 that syntax for a true private class scope variable. The key name conflict seems niche outside of key based data structures. I wrote an ORM system before and just used a key called "internal" to hold data in the past to get around a similar conflict. The # sounds like a similar workaround when required but allows everything to not be hidden in a nested object which is nice. Are "protected" class fields a thing in this discussion at all? Or is the idea to use or implement a friend system later somehow? With how I use Javascript currently, and the direction I want ECMAScript to head - toward types - I don't particularly like the proposal or necessarily support its goals toward creating an ideal encapsulation. (Also I really dislike the syntax). _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
