关于废止proposal-class-fields提案的建议

在本文中，我会仔细分析新提案中field的概念矛盾，并揭示它实质上是作用域设计上的倒退。并且，该提案的错误实现，将不可避免地导致灾难。

Reject it! No more choices!

1. 概念：“Not Fields”！

对象在定义上是“属性集（object is collection of properties）¹”。因此如果Field不是属性，则它必然不属于“对象成员（collection elements of object）”这一概念集；如果Filed是属性，则public field必然与property这一现有概念冲突。

这就是现有一切矛盾的根源。

"proposal-class-fields"提案在根本上与ECMAScript对象核心概念是矛盾的，它试图说明²：对象是通过类成员来定义的一个结构，而类成员包括属性名与私有名；属性名定义的就是属性。

在这个定义中，对象是一个“类成员(字段)的映像实例”，每个字段是一个“名字*（field define by his name）*”。亦即是说，对象是名字集（object is collection of names），是字段定义的实例（instance of field definitions by class）。

该提案对概念的偷换并非只停留在叙述层面，它在实现上确实就是这么做的。如下³：

2.7 DefineField(receiver, fieldRecord)
...
  8. If fieldName is a Private Name,
    ... // add as private filed
  9. Else, // public field as property
    Assert: IsPropertyKey(fieldName) is true.
    Perform ? CreateDataPropertyOrThrow(receiver, fieldName, initValue).

我们已经明显地看到，该提案的提出是对现有对象核心概念的破坏。而 “Not Fields”，是阻止它的唯一手段。

2. 实现：再造了一次var！

对于如下定义：

class f {
   
   
    #data = 100;
    foo() {
   
   
        this.#data