How you interpret this code? -- test of a imaginary JavaScript code

[hax]

Note, this is NOT a valid code as current JavaScript syntax. So the choices below are not correct or wrong, please just choose what your intuition tell.

注意，下面的代码目前并不是合法的代码。所以后面的选择没有对错之分，请按照你的直觉选择。

var foo = 0;

class Whatever {
   var bar;

   constructor(v) {
      bar = v;
   }
   
   test() {
      ++foo;
      ++bar;
      return `${foo}:${bar}`;
   }
}

var x = new Whatever(10);
x.test(); // output 1:11
var y = new Whatever(20);
y.test(); // output 2:21

x.test(); // output?
y.test(); // output?

Please use 👍 or 👎 to vote. Use 👍 to choose what match your intuition, you could also use 👎 to denote you will never interpret the code like that. If you have other answer, please add comment. Thank you.

请用表情符号投票。👍 表示跟你的直觉相符，你也可以用 👎 表示完全不会这么想。如果你觉得有其他结果，可以留言。谢谢。

[hax]

Choice A: bar is an instance variable which each instance of Whatever have a individual bar value
选择A：bar是一个实例变量，每个Whatever的实例都有各自的bar值

3:12
4:22

[hax]

Choice B: bar is a bit like foo which shared by all the instances
选择B：bar跟foo差不多，所有实例访问的是同一个

3:22
4:23

[BigGress]

I think B is better.it's confirm to the js's grammer

[amio]

For choice B, is it drop support for instance variable? or just not shown in the code?
选项 B 是不支持创建实例变量吗？还是只是目前的代码里没有示例？

[SilentDepth]

@amio
Just not demo-ed IMO
应该只是没有示例

[hax]

@SmallGress
This is not which is better question. Don't think too much about it. Just use your intuition.
这不是一个“哪一个更好”的问题。不要想得太多，直接按你的第一直觉来就好了。

@amio
This is not a poll for which is the better syntax of instance variable. In fact I don't think poll is a good way to choose syntax of new feature because it's too complex for most programmers to see all consequences of a syntax. But we can use a poll to test a much simple, much specific issue. So this is just a test to see whether programmers would be confused if we use var to declare instance var in the class.

[zheeeng]

It will not ambiguous if we write:
写成这样就没歧义了吧：

var foo = 0;

class Whatever {
   var bar; // private instance field, use 'this->bar' for reference

   constructor(v) {
      this->bar = v;
   }
   
   test() {
      ++foo;
      this->bar++;
      return `${foo}:${this->bar}`;
   }
}

[hax]

@zheeeng
It's may much clear bar is instance var if we using class1.1 full syntax this->bar to differentiate foo, but it also throw another question, how programmers see var bar in the class as a declaration for this->bar. Anyway, this poll is try to investigate the intuitions of the shortcut form. Because if class1.1 proposal support bar as a shortcut form of this->bar, then I guess programmers will mostly use bar in the code, only use this->bar or other->bar in rare case.

使用class1.1提案的 this->bar 语法以区分 foo 当然会让大家更清楚 bar 实际上是实例变量，不过有另外一个问题，程序员是否第一眼就认为class里的var bar会对应this->bar呢？但这些不是本测试的目的，本测试是为了看看直接写成bar的这个方式是否符合大家的直觉。因为如果class1.1提案支持把this->bar简写为bar，那么估计我们大部分时候在代码里都是直接写bar，只有少数时候会使用this->bar（函数里有bar同名变量）或other->bar（other是外面传进来的另一个实例）。

[CodeDaraW]

My intuition tells me that just treat Class as a function and then translate the code like:

var foo = 0;

function Whatever(v) {
  var bar;

  bar = v;

  return {
    test: function () {
      ++foo;
      ++bar;
      return foo + ":" + bar;
    }
  }
}

var x = new Whatever(10);
x.test(); // 1:11
var y = new Whatever(20);
y.test(); // 2:21

x.test(); // 3:12
y.test(); // 4:22

Of course, they are not equivalent. The point I want to express is that my intuition treated bar as a local variable, rather than an instance variable. x.test and y.test are both closures, they share the same function body definition but store different lexical environments.

That's why I choose A.

[dou4cc]

@hax 切记class只是语法糖啊！Choice A是搞哪一出？
截至ES2018，Whatever.prototype.a=function(){}能写成class形式（像这样：class Whatever{a(){}}），Whatever.prototype.b=1却写不成class形式。想问这种不一致是有意的吗？

---

Keep in mind that class is just syntactic sugar! What is Choice A doing?
In ES2018, Whatever.prototype.a=function(){} can be rewriten in class-style like class Whatever{a(){}} while Whatever.prototype.b=1 cannot. Tell whether the inconsistency is deliberate.

[dou4cc]

For Choice A, consider:

Whatever.prototype.test.call(x); // ????
y.test.call(x); // ????
Whatever.prototype.test.call(class{var bar = 0}); // ????
Whatever.prototype.test.call(class{}); // ????
Whatever.prototype.test.call(class{var foo = 0}); // ????
(function(){return foo}).call(class{var foo = 0}); // ????
(() => foo).call(class{var foo = 0}); // ????

[hax]

@dou4cc

这个测试只是用来看看大家对 class 级别的 var 直觉上的反应。不用想得太深。
当然，如果你对这种用法感到很抵触，可以通过投票表示。

This is only a test to investigate the intuition of the programmers if they see class-level var usage. Don't think too much. But you of coz can vote against it if you think it's a "wrong" thing.

我个人建议不要把class当做语法糖来看待，而是把prototype看成是class的内部细节。当然基于prototype必然对ES6+ class的设计产生影响，你说的只有“方法”没有“属性/数据字段”就是后果之一。这里有个有趣的事情是，如果一定要说语法糖的话，你觉得class-level的var应该是每实例上还是原型上的属性呢？还是其他？

I will recommend that don't treat class as syntactic sugar, but treat prototype as the inner details of class. Of coz, the fact that ES6+ class is based on prototype cause consequence to the design, one of it is only "methods" but no "properties/data fields". I doubt how you think class-level var in the view of syntactic sugar? Property per-instance, or property on the prototype? or other?

至于后面你写的那些例子，这体现了你在考虑this动态绑定的语义问题。当然这是一个重要的问题，提案必须要给出精确的语义。但是这不代表这对于实际代码一定是特别重要的问题。可以做某件事（比如把 class 上的方法扒下来绑一个其他 context 调用），不代表你真的有需求在代码里这么用。我希望咱们能聊一些更为切实的 use case，看看会有什么问题。谢谢。

About the code examples of call usage, I believe you are considering the semantic of this binding. It's a important issue for the spec, the proposal should give precise semantic for every possible usage. But I don't think it's a important issue for real coding. We have the ability to do something (like extract the method from a instance of a class and call it with other context), don't necessarily mean you have a real use case in the daily coding. I hope we can focus on some much real use cases, and figure out if there is any problem. Thank you.

[dou4cc]

@hax

我个人建议不要把class当做语法糖来看待，而是把prototype看成是class的内部细节。当然基于prototype必然对ES6+ class的设计产生影响，你说的只有“方法”没有“属性/数据字段”就是后果之一。这里有个有趣的事情是，如果一定要说语法糖的话，你觉得class-level的var应该是每实例上还是原型上的属性呢？还是其他？

I choosed B.

In ES2018, Whatever.prototype.a=function(){} can be rewriten in class-style like class Whatever{a(){}} while Whatever.prototype.b=1 cannot. Tell whether the inconsistency is deliberate.

---

至于后面你写的那些例子，这体现了你在考虑this动态绑定的语义问题。当然这是一个重要的问题，提案必须要给出精确的语义。但是这不代表这对于实际代码一定是特别重要的问题。可以做某件事（比如把 class 上的方法扒下来绑一个其他 context 调用），不代表你真的有需求在代码里这么用。我希望咱们能聊一些更为切实的 use case，看看会有什么问题。谢谢。

You are against not only prototype but also implementation of existing native methods.

Carefully review the following usual code:

[].map.call(["1", "2", "3"], a => +a); // [1, 2, 3]
[].map.call("123", a => +a); // [1, 2, 3]
[].map.call(null, a => +a); // TypeError

When binding context is needed, #44 (comment) is just ok. To support switching to different context, what we need is not syntax.