I hadn't read the proposal properly, but the thrust of my point is the same, read remove/add `#` instead of "replace with this"
On Fri, 12 Jan 2018, 2:47 am Naveen Chawla, <naveen.c...@gmail.com> wrote: > Massive drawback of the # semantic: making a private variable public (a > common transition when the usage of a class evolves) requires a lot more > refactoring, since you have to remove every # for the variable across the > class and replace it with `this`. Failing to do so in just 1 instance > creates a bug. The same drawback applies for privatizing a public variable, > in reverse. > > Besides which as an instance variable I want to learn `this` as the access > prefix. I don't want to have to learn 2 different access prefixes, one for > public and one for private. Access control in code only has one real > material advantage: simplifying the public interface of a class by hiding > factors that have no use from outside it. This is not big enough of an > advantage to introduce a new access prefix, which can lead to a plethora of > bugs due to confusion and/or publicization/privatization transitions during > the evolution of one's system. > > On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, <isiahmead...@gmail.com> > wrote: > >> Inline >> >> ----- >> >> Isiah Meadows >> m...@isiahmeadows.com >> >> 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 >> <warcraftthre...@sbcglobal.net> 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 >> > es-discuss@mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
