Inline -----
Isiah Meadows [email protected] Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews <[email protected]> wrote: > > 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). The issue with leveraging static typing is that JS has never been a statically typed language. Also, private fields are generally something you shouldn't need static types to detect - even without the sigil, it *is* in fact possible to require something like `private foo` as a declaration and alter property lookup within classes to check for local private names (for class instances) before public ones. (Decided to create a GH issue out of this: https://github.com/tc39/proposal-class-fields/issues/69) > 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. Note: not even Java allows subclasses to access superclasses' private fields. > > 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? See https://github.com/tc39/proposal-decorators/issues/25. > > > 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
