Explore a more JS-like syntax

[mgtitimoli]

I would like to highlight this issue recently created in the Private Methods Proposal to discuss it also here, as IMHO it addresses in a clean and understandable way the main topics that made this other proposal to emerge.

[Guxingzhe]

Why not use this grammatical sugar: attributes or methods that begin with an underscore are privatized without the need to add the keywords "private" or "#". For example:

class Animal {
  _type = "human" // private attribute；
  age = 21; // public attribute；

  constructor(type, age) {
    this._type = type;
    this.age = age;
  }
  // private method
  _privateMethod() {
    console.info("this is my private method");
  }
  // public method
  toString() {
    this._privateMethod();
    return '(' + this._type + ', ' + this.age + ')';
  }
  // _type get set function
  get Type() {
    return _type;
  }
  set Type(type) {
    _type = type;
  }
}
let animal = new Animal();
animal.Type // yes
// _type cannot be accessed through this, age can;
animal._type // error: private attribute
animal.age // yes
// _privateMethod cannot be accessed through this, toString can;
animal._privateMethod() // error:
animal.toString() // yes

Don't you think it's more concise? There's not much difference in code style.

[hax]

@Guxingzhe Your proposal breaks the compatibility, for example, _privateMethod() {} is a non-private method now.

[Guxingzhe]

@hax Later, I remembered that loadash and undercode are underlined, which can destroy the ecology of the library; you have a point of breaking compatibility; I just think that some languages use the underscore to say privatization, and I think this javascript can be emulated. However, the use of "#" is acceptable, it is only a matter of time; ps: da lao ye shi yong fan yi ruan jian fan yi ying wen de me ?

[hax]

@Guxingzhe

However, the use of "#" is acceptable, it is only a matter of time

I agree # is workable, but how it can acceptable for everyone, I am not sure.

PS. 全用翻译软件是不行的，它只能做辅助。

PPS. 作为大佬 😜，我一般很有信心说服大家，某个新特性不错，你们应该用。但是 # 这件事情就不一样。尽管“# 是新的 _”从理性上是可以说服不少人，但是“#”的感情色彩太强烈，我预期有些朋友从感情上就是不接受它。这使得这个问题变成了一个靠理性无法解决的问题。类似的“非理性”问题，比如tab vs space之圣战。但是tab/space至少在实践上不是问题，因为工具可以无缝转换，程序员完全可以忽略之。但拒绝使用#的人所使用的其他private方案（比如TS private、基于symbol的private、传统closure private pattern）和 # 方案是不能无缝转换的，因为语义上是有差异的。甚至连 _x 也并不能无缝转化到 #x，因为 _x 在很多时候其实被当成 protected 用。这是为什么口号是“# 是新的 _”，而不是“# 是更好的的 _”。所以我预期结果就是，你又多了一种新的private解决方案要学，甚至出现一个项目里同时几种private并存的情况。因为语义有微秒差异，所以你也不敢随便去转，转了说不定出bug。我认为总体上这对整个JS生态并没有好处。这是为什么我反对现在的 #priv 提案的原因之一。另外，public field看上去好像没问题，其实也有一堆奇怪问题。这里就不详述了。

[Guxingzhe]

"#"符号应该只有js开了先河，这个实践方面有待验证。“总体上这对整个JS生态并没有好处”这个也说不定。如果兼容性做的好的话，不影响以前版本的代码，还是可以照样用以前的风格写代码。像模块化、lambda等新属性，不也慢慢的有人接受的？我也慢慢的试着习惯这种风格的写法。新生事物最能接受的还是那些新生代，老人家最难接受。

[hax]

@Guxingzhe 你可能在暗示我是老人家所以不接受？🤪 你如果听过我的一些演讲就知道了，总体上我是非常推崇各种新的特性的。关于 #priv ，其实我很早就接受的，你可以看去年我在QCon北京的演讲：http://www.infoq.com/cn/presentations/how-programming-languages-evolve-take-js-private-as-an-example 。另外，实际上老家伙反而更能忍受奇怪的语法呢。我反对这个提案其实完全不是因为不接受新风格，而是深思熟虑它可能造成的结果。这里一时半会儿讲不清楚。后续我会找机会在国内组织一个关于此的讨论会。

[Guxingzhe]

@hax 昨天别人发给我的链接，可能你也看过。我资历尚浅，也许考虑的不够周到。不过你们说的都有理呢。

[hax]

@Guxingzhe 我当然是都看过的。实际上我可能是国内参与这个讨论最多的人。这东西确实看起来简单，但是讨论起来非常复杂。还是推荐你先看一下我之前那个演讲。

[Guxingzhe]

@hax 好的！不过公司限制网络了，有空看一下。

[ljharb]

@hax @Guxingzhe it’d be nice if you could provide English translations for that back and forth.

[hax]

@ljharb I would like you to mark these conversation as off-topic, thank you.

---

For anyone have interest in our conversation, here is the translation:

Guxingzhe: PS. Hi guru, do you also use translation software for all discussion in English?

Me: PS. You can't totally rely on translation software, though it could be a good helper.

PPS. As a "guru (in China JS community)" 😜, normally I have strong confidence to convince most programmers that a new feature is good, and you should learn and use it. But I found # is very different. Yes “# is new _” could be a good reason to convince many, but # is too emotional that I found some friends just can't accept it. This make the issue can not be solved by rationality. Such "issue of irrationality", like the holy war of tab vs space. But at least tab/space is not a real issue in practice, because tools/IDEs can convert them losslessly so programmers can just ignore it. But those who refuse # are using other privacy solutions (like TS private, symbol-based solution, classical closure private pattern, weakmap-based api, etc.), and such solutions can not be converted to # seamlessly. The semantics are different. Even _x can not be converted to #x seamlessly too, because in many cases _x is used as "protected" semantic. This is why the slogan is “# is new _”, not “# is better _”. So I'm afraid the final result is, all js programmers will just have another new private solution to learn, and they will face several privacy solutions coexist in one project. Because the difference of semantics are subtle, conversion will not as easy as you imagine, and hasty actions will introduce bugs. (Then the objectors of # will improve the faith that # is bad.) Overall, I think such situation is not good to the whole ecosystem. This is why I am against current proposal. On the other hand, it seems at least public field is ok, but it also have many weird issues, but I won't go into that here.

Guxingzhe: JS is the first language adopt "#" (for private), and only practice can tell whether it's ok or not. "Overall, such situation is not good to the whole ecosystem" -- Not sure. We can always write the code using old style. The new features, like ES module, lambda could be accepted slowly. I also slowly tried to get used to these new features. New generation programmers can accept the new things quickly, which elder programmers can not.

Me: You may be suggesting that I don't accept it because I am an old man? 🤪 If you have seen my speeches, you'll know that I generally recommend adopting new features. Regarding #priv, I actually had accepted it very early and introduced it to China community. You can see my speech at QConBeijing last year: http://www.infoq.com/cn/presentations/how-programming-languages-evolve-take-js-private-as-an-example. And, in fact, the old guys are more tolerant than youngers for strange syntax (because old guys normally have seen more languages in different syntax, and be more practical.) I object to this proposal not because it's a new style, but because I'm very worry about the possible consequences of this proposal. It’s not easy to explain all in a short comment. This topic is too complex. Again, you should watch the video of my speech first. And I will organize a seminar on this topic in China next month.

Guxingzhe: Ok! I will watch it if I have time.