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

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

Reject it! No more choices!

1. 概念:“Not Fields”!

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

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

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

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

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

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() 

你可能感兴趣的:(JavaScript,javascript,ecmascript,语言)