5 ms·

Seems like a pretty fair and well though out solution after reading the latest response by bakkot.

by watty 9y ago

Andrex 9y ago
Agreed. I've been following the spec for a few months and while # is "ugly," it serves the purpose of the concept well and works with the current spec/implementations without much headache. Seems like a win-win to me and I haven't seen a convincing argument for why private # properties shouldn't move forward as they are.
just_astounded 9y ago
I think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 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.
- model_m_warrior 9y ago
  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).
- dmitriid 9y ago
  Pushback from the community means nothing to TC39. Zilch. Zero. Nada. The only instance of something dropped was cancelable observables. AFAIR it was only because some other group at Google opposed it. Everything else is carried full steam ahead. Enjoy your import() instead of the vastly superior System.loader. Enjoy your hashes as member access specifiers. Dumpster fire. Template literals. BigInts. `new.target`. Dumpster fire. `import.meta`. Dumpster fire
  - just_astounded 9y ago
    While it hasn't changed their minds, I do see the authors of the proposal actively discussing and engaging with the community. That's better than nothing, I suppose.
bcherny 9y ago
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#issuecomment-319964681 https://github.com/tc39/proposal-class-fields/issues/15#issu...
- aturek 9y ago
  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.
  - pmalynin 9y ago
    Also C#
- JoshTriplett 9y ago
  > 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 those of another instance of itself, so that it can do comparisons, combinations, or other operations.
  - spankalee 9y ago
    It gets really tricky when you have any kind of polymorphism, intended or not. If you accept instances of your own class as arguments to a method, you may be templated to think you can access the private fields of those arguments, even if instanceof checks pass, but they may not be there.

Seems like a pretty fair and well though out solution after reading the latest response by bakkot.

by watty 9y ago

Seems like a pretty fair and well though out solution after reading the latest response by bakkot.

Agreed. I've been following the spec for a few months and while # is "ugly," it serves the purpose of the concept well and works with the current spec/implementations without much headache. Seems like a win-win to me and I haven't seen a convincing argument for why private # properties shouldn't move forward as they are.

just_astounded 9y ago

I think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 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.

model_m_warrior 9y ago
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).
dmitriid 9y ago
Pushback from the community means nothing to TC39. Zilch. Zero. Nada. The only instance of something dropped was cancelable observables. AFAIR it was only because some other group at Google opposed it. Everything else is carried full steam ahead. Enjoy your import() instead of the vastly superior System.loader. Enjoy your hashes as member access specifiers. Dumpster fire. Template literals. BigInts. `new.target`. Dumpster fire. `import.meta`. Dumpster fire
- just_astounded 9y ago
  While it hasn't changed their minds, I do see the authors of the proposal actively discussing and engaging with the community. That's better than nothing, I suppose.

bcherny 9y ago

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#issuecomment-319964681 https://github.com/tc39/proposal-class-fields/issues/15#issu...

aturek 9y ago
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.
- pmalynin 9y ago
  Also C#
JoshTriplett 9y ago
> 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 those of another instance of itself, so that it can do comparisons, combinations, or other operations.
- spankalee 9y ago
  It gets really tricky when you have any kind of polymorphism, intended or not. If you accept instances of your own class as arguments to a method, you may be templated to think you can access the private fields of those arguments, even if instanceof checks pass, but they may not be there.