Why are private properties so sorely needed? Ruby is an OOP language, and gets along just fine without it.
JavaScript TC39 implementing hashmark private class fields
31–40 of 81 posts
Re: JavaScript TC39 implementing hashmark private class fields
#32Earlier quoted context omitted.
> From reading the thread it sounds like some feel that the addition of private members is being accomplished by fiat rather than community consensus. There's a difference between "community consensus" and "consensus of the people posting comments on this github issue".
What evidence is there for the "silent majority"? There's no good way to collect that kind of data (after all, they're silent). It sounds like a baseless statement of "fact" to bolster an otherwise losing position.
Look at the harsh responses that we can already see on HN and you will understand why I usually prefer to remain silent on such topic. A lot JS devs seem to feel very strongly about any kind of change.
Re: JavaScript TC39 implementing hashmark private class fields
#33Personally I'm not against classes, if someone prefers to use classes instead of prototype it's fine by me.
What I don't understand is why the TC39 is pushing for classes and classic OOP instead of other more pressing issues. You can accomplish OOP with prototypes.
IMO the lack of type checking is much more problematic. Flow and TypeScript are just adding a new layer of problems to an already convoluted workflow.
Re: JavaScript TC39 implementing hashmark private class fields
#34There's a cute use of WeakMap to do private fields in a GC-friendly way
let ages = new WeakMap()
export class Person {
constructor(name, age) {
this.name = name
ages.set(this, age)
}
// ages.get(this)
}Re: JavaScript TC39 implementing hashmark private class fields
#35Why are private properties so sorely needed? Ruby is an OOP language, and gets along just fine without it.
You can declare visibility in Ruby: https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classe...
It can usually (always?) be gotten around though.
Re: JavaScript TC39 implementing hashmark private class fields
#36This is the primary reason I didn't like the idea of adding "classes" to JavaScript in the first place. Classical OOP doesn't really have a place here and all it does is invite the wrong type of thinking into the language.
Agreed. We already had solutions for inheritance, etc... using prototypes, which are more powerful than classic OOP. Now we're in sort of a mess hybrid thing where issues like this are mostly unsolvable in a clean way.
[deleted]
Re: JavaScript TC39 implementing hashmark private class fields
#37Personally I'm not against classes, if someone prefers to use classes instead of prototype it's fine by me. What I don't understand is why the TC39 is pushing for classes and classic OOP instead of other more pressing issues. You can accomplish OOP with prototypes. IMO the lack of type checking is much more problematic. Flow and TypeScript are just adding a new layer of problems to an already convoluted workflow.
You realise JS classes are syntactic sugar for prototypes, right?
Re: JavaScript TC39 implementing hashmark private class fields
#38Why are private properties so sorely needed? Ruby is an OOP language, and gets along just fine without it.
You can declare visibility in Ruby: https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classe... It can usually (always?) be gotten around though.
Right. You can say something's "private", but there's always a way to access it. As far as I'm aware, this has never been an actual problem, and in fact has been useful since you can "patch" a library if you really need to.
Re: JavaScript TC39 implementing hashmark private class fields
#39Earlier quoted context omitted.
I read through the thread, and the proposal sounds crazy to me. 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? 2. The # syntax is not extensible. If TC39 decides to add protected, internal, etc. modifiers in the future, what will they look like? We should be…
> 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? C++ works that way, and several other languages do as well. And the use case mentioned in that comment is exactly the reason: the implementation of a class knows how to access both its own private fields and th…
[deleted]
Re: JavaScript TC39 implementing hashmark private class fields
#40Why are private properties so sorely needed? Ruby is an OOP language, and gets along just fine without it.
Admittedly I have barely used Ruby, but isn't the fact that those "attr_reader"s have to be declared explicitly an indication that the fields are private by default?