7 ms·

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 counte

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.
- deleted 9y ago
  [deleted]
pitaj 9y ago
The answer to #2 is that you can just put a private / protected keyword in front of the `#prop` declaration. The difference between public and protected, etc is larger than the difference between private and protected, etc.
jkrems 9y ago
Downvoting this comment because: 1. Afaik every single OO language allows this. I wouldn't know of prior art for the opposite behavior (only allowing access to the same object). 2. TypeScript works under different constraints and - for all intends and purposes - doesn't implement private properties when it comes to the final, running program. The reasons why TypeScript isn't a battle test solution are laid out pretty explicitly in the Github thread.
- RyanCavanaugh 9y ago
  The only mainstream language I'm aware of (having looked into this before because someone complained about it re: TypeScript) that disallows cross-instance private access is Ruby.
- bcherny 9y ago
  > Afaik every single OO language allows this. Ruby and Scala disallow it, to name two (edit: to clarify, Scala supports both modes via private and private[this]). I stand corrected on Java, C#, and C++. > The reasons why TypeScript isn't a battle test solution are laid out pretty explicitly in the Github thread. I didn't see that, can you point me to it? Yes, in TS it's a compile-time-only check (as are all TS checks), but what does that have to do with reusing the same keyword for a runtime check?
munificent 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? Almost every statically typed OOP language works this way. In C++, Java, and C#, privacy is class-based, not instance-based. Privacy is instance-based in Smalltalk and, as I understand it, has been a long-time source of frustration. It makes it very difficult to implement things like an equality method so that an object can compare itself to another of its own type without breaking its own encapsulation. If you think about it from the perspective of software engineering (and not security, which is generally not what language-level privacy is for), instance-based privacy has no benefits over class-based privacy. The goal of access control is to encapsulate regions of code from each other so that modification to one doesn't affect others. It establishes fences between different parts of the program to make them less coupled to each other and easier to independently change. Every instance of the same class shares the exact same code, so there is no point in preventing access between them. It's not like you can encapsulate things such that a change to class A doesn't require a change to... class A. That's the same class that you're already touching. > 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. I believe those rely on static analysis, which JavaScript does not have.
jasonlotito 9y ago
[1] While others have corrected you, just to be clear, this is something they addressed in the FAQ. https://github.com/tc39/proposal-private-fields/blob/master/FAQ.md#why-does-this-proposal-allow-accessing-private-fields-of-other-instances-of-the-same-class-dont-other-languages-normally-forbid-that https://github.com/tc39/proposal-private-fields/blob/master/... [2] This is addressed here: https://github.com/tc39/proposal-private-fields/blob/master/DECORATORS.md https://github.com/tc39/proposal-private-fields/blob/master/...

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.
deleted 9y ago
[deleted]

pitaj 9y ago

The answer to #2 is that you can just put a private / protected keyword in front of the `#prop` declaration. The difference between public and protected, etc is larger than the difference between private and protected, etc.

jkrems 9y ago

Downvoting this comment because: 1. Afaik every single OO language allows this. I wouldn't know of prior art for the opposite behavior (only allowing access to the same object). 2. TypeScript works under different constraints and - for all intends and purposes - doesn't implement private properties when it comes to the final, running program. The reasons why TypeScript isn't a battle test solution are laid out pretty explicitly in the Github thread.

RyanCavanaugh 9y ago
The only mainstream language I'm aware of (having looked into this before because someone complained about it re: TypeScript) that disallows cross-instance private access is Ruby.
bcherny 9y ago
> Afaik every single OO language allows this. Ruby and Scala disallow it, to name two (edit: to clarify, Scala supports both modes via private and private[this]). I stand corrected on Java, C#, and C++. > The reasons why TypeScript isn't a battle test solution are laid out pretty explicitly in the Github thread. I didn't see that, can you point me to it? Yes, in TS it's a compile-time-only check (as are all TS checks), but what does that have to do with reusing the same keyword for a runtime check?

munificent 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? Almost every statically typed OOP language works this way. In C++, Java, and C#, privacy is class-based, not instance-based. Privacy is instance-based in Smalltalk and, as I understand it, has been a long-time source of frustration. It makes it very difficult to implement things like an equality method so that an object can compare itself to another of its own type without breaking its own encapsulation. If you think about it from the perspective of software engineering (and not security, which is generally not what language-level privacy is for), instance-based privacy has no benefits over class-based privacy. The goal of access control is to encapsulate regions of code from each other so that modification to one doesn't affect others. It establishes fences between different parts of the program to make them less coupled to each other and easier to independently change. Every instance of the same class shares the exact same code, so there is no point in preventing access between them. It's not like you can encapsulate things such that a change to class A doesn't require a change to... class A. That's the same class that you're already touching. > 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. I believe those rely on static analysis, which JavaScript does not have.

jasonlotito 9y ago

[1] While others have corrected you, just to be clear, this is something they addressed in the FAQ. https://github.com/tc39/proposal-private-fields/blob/master/FAQ.md#why-does-this-proposal-allow-accessing-private-fields-of-other-instances-of-the-same-class-dont-other-languages-normally-forbid-that https://github.com/tc39/proposal-private-fields/blob/master/... [2] This is addressed here: https://github.com/tc39/proposal-private-fields/blob/master/DECORATORS.md https://github.com/tc39/proposal-private-fields/blob/master/...