10 ms·

If `example.myVar = 500` can throw errors, then is the private field really private? Since now it's existence can break the public interface, and changing it to

If `example.myVar = 500` can throw errors, then is the private field really private? Since now it's existence can break the public interface, and changing it to `myOtherVar` during a refactor can break existing code. That removes a major benefit of private fields (which is to be able to change implementation details without breaking the public interface) I don't think anyone really loves the syntax, but there doesn't seem to be much of a better way of doing it.

franciscop 8y ago
What happens if you do `example.#myVar = 500`? Does it throw an error? Wouldn't it be the same situation?
- Klathmon 8y ago
  as of right now, `example.#myVar` isn't valid syntax, which is the reason that the # sigil was chosen. It's not possible to have current code that works like that, so defining new properties for that code (that it can only be used inside the class as a private field) isn't breaking anything. In other words, outside of the class implementation, `example.#myVar` is always an error, regardless of the existence of a private field or not, and it will always be an error with or without this proposal. And inside the class it's only legal if the private field was defined in the class.
- __ryan__ 8y ago
  The difference is that when you type example.myVar = 400 you are setting a property names "myVar" on the object to 400. When you type example.#myVar you are trying to set example's private field to 400. The intentions are distinct and it is not costly to determine at the call site what you're trying to do.
  - earthboundkid 8y ago
    What if I have private values I want to access programmatically? Ie. fields = ['#foo', '#baz', '#bar']; fields.forEach(field => { this[field] = frobnicate(field) }); ?
    - __ryan__ 8y ago
      I don't know what the spec's solution for that would be, but what you've typed would not work. Specifically because when I say `this.#foo` it is not a property on the object named "#foo". It is just the syntax for looking up a private field referenced by the literal #foo.
      - Klathmon 8y ago
        The spec's solution is to not solve that problem ;) Dynamic property access isn't allowed for private fields, so it kind of side steps that whole issue.
- chacham15 8y ago
  Correction: What happens if you do `example['#myVar'] = 500`? Does it throw an error? Wouldn't it be the same situation?
  - Klathmon 8y ago
    dynamic access to private fields is considered a "non-goal" of sorts, so `example['#myVar']` will act the same as it does now, it will always refer to the public property of that name. https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-doesnt-thisx-access-the-private-field-named-x-given-that-thisx-does https://github.com/tc39/proposal-class-fields/blob/master/PR...
    - franciscop 8y ago
      Then what about inside the class? What about `this['#myVar']`? Is it different from `this.#myVar`? If they are different it's very inconsistent and IMHO a lot worse. If they are the same, it's more confusing and still worse than the alternative suggested... what a mess. On one hand I follow a more functional programming style so this won't affect me but on the other I worry about trying to understand other people's code (especially very serious programming [tm]).
      - Klathmon 8y ago
        `this['#myVar']` will access the public field named `#myVar`, so it's the same as the `example` method. >If they are different it's very inconsistent and IMHO a lot worse. It is called out in the link I posted above as a "downside", and I agree that it sucks, but there aren't any other good options for this without breaking compatibility with current code. >I worry about trying to understand other people's code Luckily there is one big benefit to this that makes the impact of the weirdness surrounding the naming much less awful. Because of the "hard encapsulation" that the private fields have, they are literally and explicitly un-viewable, un-accessible, and un-usable outside of the class body. So the amount of complex meta-programming and many of the reasons you'd want dynamic property access in the first place (iterating, monkey-patching, using arbitrary strings as keys, computed keys, etc...) aren't applicable, and if you really want those features but also with privacy, you can nest a plain object as a private field and work with it that way just the same. So it may have some gotchas, but because the proposal is intentionally restricted as much as possible, and it explicitly disallows a lot of the metaprogramming that can be common and it only allows a very simple lookup syntax, the weirdness is very well contained, and at worst will be confined to between the opening and closing brace of a `class` statement.
throwaway427 8y ago
> then is the private field really private What are some of the other languages that interpret "private" as never exposing the existence of that field to a public consumer? Most languages I've used don't expose the _value_ of the field...
- Klathmon 8y ago
  I'm honestly not sure, but even taken in isolation it's a convincing argument to me. See [0] for some info straight from the proposal, but the gist is doing it this way makes it so that you never have to worry about name collisions for private fields. Subclassing, superclassing, and object "monkey patching" all can continue to work as-is with no changes, and none of them have to worry about the existence of private fields complicating implementations, and the classes with private fields can feel free to change and rename them as much as possible, even within patch versions of libraries, since they cannot impact any code outside of the class under any circumstances. That's a pretty powerful guarantee to give which GREATLY simplifies working with them. If I want to extend the react component class, I don't need to worry that my `#component` private field is going to break if an update to the react component class adds their own `#component` field, or if a user of my library tries to do something like this: const fancyObj = new FancyObj() fancyObj.tag = Symbol('tag') Which I'll admit to having used in some cases where I want to tag a bunch of otherwise identical objects which will be thrown into an array and then be able to easily pluck out the ones I tagged later. Without true encapsulation, that code above would break if they changed the private interface to use the `.tag` field internally, and I would have no idea because it is consitered a private interface and wouldn't need to be documented or maintained across versions. [0] https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#what-do-you-mean-by-encapsulation--hard-private https://github.com/tc39/proposal-class-fields/blob/master/PR...
  - throwaway427 8y ago
    Huh, they just took all the issues with inheritance and made them more confusing! There is nothing addressed here that can't be solved with composition. This seems like an odd step for an aspiring functional language to take...

franciscop 8y ago

What happens if you do `example.#myVar = 500`? Does it throw an error? Wouldn't it be the same situation?

Klathmon 8y ago
as of right now, `example.#myVar` isn't valid syntax, which is the reason that the # sigil was chosen. It's not possible to have current code that works like that, so defining new properties for that code (that it can only be used inside the class as a private field) isn't breaking anything. In other words, outside of the class implementation, `example.#myVar` is always an error, regardless of the existence of a private field or not, and it will always be an error with or without this proposal. And inside the class it's only legal if the private field was defined in the class.
__ryan__ 8y ago
The difference is that when you type example.myVar = 400 you are setting a property names "myVar" on the object to 400. When you type example.#myVar you are trying to set example's private field to 400. The intentions are distinct and it is not costly to determine at the call site what you're trying to do.
- earthboundkid 8y ago
  What if I have private values I want to access programmatically? Ie. fields = ['#foo', '#baz', '#bar']; fields.forEach(field => { this[field] = frobnicate(field) }); ?
  - __ryan__ 8y ago
    I don't know what the spec's solution for that would be, but what you've typed would not work. Specifically because when I say `this.#foo` it is not a property on the object named "#foo". It is just the syntax for looking up a private field referenced by the literal #foo.
    - Klathmon 8y ago
      The spec's solution is to not solve that problem ;) Dynamic property access isn't allowed for private fields, so it kind of side steps that whole issue.
chacham15 8y ago
Correction: What happens if you do `example['#myVar'] = 500`? Does it throw an error? Wouldn't it be the same situation?
- Klathmon 8y ago
  dynamic access to private fields is considered a "non-goal" of sorts, so `example['#myVar']` will act the same as it does now, it will always refer to the public property of that name. https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-doesnt-thisx-access-the-private-field-named-x-given-that-thisx-does https://github.com/tc39/proposal-class-fields/blob/master/PR...
  - franciscop 8y ago
    Then what about inside the class? What about `this['#myVar']`? Is it different from `this.#myVar`? If they are different it's very inconsistent and IMHO a lot worse. If they are the same, it's more confusing and still worse than the alternative suggested... what a mess. On one hand I follow a more functional programming style so this won't affect me but on the other I worry about trying to understand other people's code (especially very serious programming [tm]).
    - Klathmon 8y ago
      `this['#myVar']` will access the public field named `#myVar`, so it's the same as the `example` method. >If they are different it's very inconsistent and IMHO a lot worse. It is called out in the link I posted above as a "downside", and I agree that it sucks, but there aren't any other good options for this without breaking compatibility with current code. >I worry about trying to understand other people's code Luckily there is one big benefit to this that makes the impact of the weirdness surrounding the naming much less awful. Because of the "hard encapsulation" that the private fields have, they are literally and explicitly un-viewable, un-accessible, and un-usable outside of the class body. So the amount of complex meta-programming and many of the reasons you'd want dynamic property access in the first place (iterating, monkey-patching, using arbitrary strings as keys, computed keys, etc...) aren't applicable, and if you really want those features but also with privacy, you can nest a plain object as a private field and work with it that way just the same. So it may have some gotchas, but because the proposal is intentionally restricted as much as possible, and it explicitly disallows a lot of the metaprogramming that can be common and it only allows a very simple lookup syntax, the weirdness is very well contained, and at worst will be confined to between the opening and closing brace of a `class` statement.

throwaway427 8y ago

> then is the private field really private What are some of the other languages that interpret "private" as never exposing the existence of that field to a public consumer? Most languages I've used don't expose the _value_ of the field...

Klathmon 8y ago
I'm honestly not sure, but even taken in isolation it's a convincing argument to me. See [0] for some info straight from the proposal, but the gist is doing it this way makes it so that you never have to worry about name collisions for private fields. Subclassing, superclassing, and object "monkey patching" all can continue to work as-is with no changes, and none of them have to worry about the existence of private fields complicating implementations, and the classes with private fields can feel free to change and rename them as much as possible, even within patch versions of libraries, since they cannot impact any code outside of the class under any circumstances. That's a pretty powerful guarantee to give which GREATLY simplifies working with them. If I want to extend the react component class, I don't need to worry that my `#component` private field is going to break if an update to the react component class adds their own `#component` field, or if a user of my library tries to do something like this: const fancyObj = new FancyObj() fancyObj.tag = Symbol('tag') Which I'll admit to having used in some cases where I want to tag a bunch of otherwise identical objects which will be thrown into an array and then be able to easily pluck out the ones I tagged later. Without true encapsulation, that code above would break if they changed the private interface to use the `.tag` field internally, and I would have no idea because it is consitered a private interface and wouldn't need to be documented or maintained across versions. [0] https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#what-do-you-mean-by-encapsulation--hard-private https://github.com/tc39/proposal-class-fields/blob/master/PR...
- throwaway427 8y ago
  Huh, they just took all the issues with inheritance and made them more confusing! There is nothing addressed here that can't be solved with composition. This seems like an odd step for an aspiring functional language to take...