This 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.
JavaScript TC39 implementing hashmark private class fields
11–20 of 81 posts
Re: JavaScript TC39 implementing hashmark private class fields
#12Can someone provide some context? This link just drops you into the middle of the argument.
Some in the JavaScript community have been asking for private members as a language feature and some folks do not want this as there is a subset of JavaScript programmers who worry about many concepts from OOP "polluting" the relative minimalism of JavaScript. A fear I share to a certain extent. From reading the thread it sounds like some feel that the addition of private members is being accomplished by fiat rather…
> 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".
Re: JavaScript TC39 implementing hashmark private class fields
#13This 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.
Re: JavaScript TC39 implementing hashmark private class fields
#14Seems like a pretty fair and well though out solution after reading the latest response by bakkot.
I think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 and other places, you'll see this massive push back from the community, yet the proposal is moving forward regardless.
Re: JavaScript TC39 implementing hashmark private class fields
#15I honestly do not see the need for these bloated features being added to Js just to appease programmers who refuse to learn a differing methodology.
Re: JavaScript TC39 implementing hashmark private class fields
#16Kinda disappointing. I don't really like the # for privates. It's not an elegant solution. It feels a bit like a one-off hack honestly.
There's not really a better way while maintaining encapsulation.
Don't we already have solutions (closures/WeakMap) for hard encapsulation? Seems like '#' just pollutes the language and isn't really needed.
Re: JavaScript TC39 implementing hashmark private class fields
#17Seems like a pretty fair and well though out solution after reading the latest response by bakkot.
I think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 and other places, you'll see this massive push back from the community, yet the proposal is moving forward regardless.
Gotta get into the enterprise somehow. Even if that means bloating the language so its easier for the career desk jockeys to use (ie: dont ask them to learn something new).
Re: JavaScript TC39 implementing hashmark private class fields
#18Seems like a pretty fair and well though out solution after reading the latest response by bakkot.
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 looking to TypeScript's private/protected modifiers as a battle tested solution that fits the existing convention set by the "static" modifier.
---
[1] https://github.com/tc39/proposal-class-fields/issues/15#issu...
Re: JavaScript TC39 implementing hashmark private class fields
#19Earlier quoted context omitted.
Some in the JavaScript community have been asking for private members as a language feature and some folks do not want this as there is a subset of JavaScript programmers who worry about many concepts from OOP "polluting" the relative minimalism of JavaScript. A fear I share to a certain extent. From reading the thread it sounds like some feel that the addition of private members is being accomplished by fiat rather…
> 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.
Re: JavaScript TC39 implementing hashmark private class fields
#20Seems like a pretty fair and well though out solution after reading the latest response by bakkot.
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…
In answer to (1) - I'm a bit rusty, but I believe Java allows objects of the same type to access other objects' private data. I definitely agree that it's gross, but it exists elsewhere.