翻译,原始文章:“Class-fields-proposal” or “what went wrong in tc39 committee”
一直以来,我们都期望有一天能在JavaScript中较为简单地使用其他语言常见的封装语法。比如,我们想要类属性/字段的语法,并且它的实现方式并不会破坏现有的程序。现在看起来,这一天已经到来:在TC39委员会的努力之下,类字段提案已经进入stage 3
,甚至已经被Chrome实现
老实说,我很乐意写一篇文章,描述为什么您必须使用这个新功能以及如何实现它。但可惜我无法这么做。
当前提案说明
参考文档在此不赘述了,具体参考:原始说明,FAQ,规范变更。
类字段
类字段说明和用法:
class A {
x = 1;
method() {
console.log(this.x);
}
}
复制代码
从外部代码访问字段:
const a = new A();
console.log(a.x);
复制代码
一眼看去稀松平常,有些人可能会说我们在Babel和TypeScript中这样使用多年了。
但有一件事值得注意:这个语法使用[[Define]]
语义而不是我们习惯的[[Set]]
语义。这意味着实际上上面的代码不等价于以下用法:
class A {
constructor() {
this.x = 1;
}
method() {
console.log(this.x);
}
}
复制代码
而等价于下述用法:
class A {
constructor() {
Object.defineProperty(this, "x", {
configurable: true,
enumerable: true,
writable: true,
value: 1
});
}
method() {
console.log(this.x);
}
}
复制代码
尽管在这个例子下,两种用法实际表现几乎没有什么区别,但实际有一个很重要的区别。我们假设我们有一个像这样的父类:
class A {
x = 1;
method() {
console.log(this.x);
}
}
复制代码
从该父类派生出一个子类如下:
class B extends A {
x = 2;
}
复制代码
然后使用:
const b = new B();
b.method(); // prints 2 to the console
复制代码
然后为了某些(不重要的)原因,我们以一种似乎向后兼容的方式改变了A类:
class A {
_x = 1; // for simplicity let's skip that public interface got new property here
get x() { return this._x; };
set x(val) { return this._x = val; };
method() {
console.log(this._x);
}
}
复制代码
对于[[Set]]
语义,它确实是向后兼容的。 但是对于[[Define]]
不是。 现在调用b.method()
会将打印1
而不是2
到控制台。原因是在Object.defineProperty
的作用下,不会调用A
类声明的属性描述符以及其getter/setter。 因此,在派生类中,我们以类似变量词法作用域的方式隐藏了父类x
性:
const x = 1;
{
const x = 2;
}
复制代码
我们可以使用no-shadowed-variable
/no-shadow
这样的liner规则帮助我们检测常见的词法作用域变量隐藏。 但是不幸的是,不太可能有人会创建no-shadowed-class-field
这样的规则帮助我们规避类字段的隐藏。
尽管如此,我并不是[[Define]]
语义的的坚定反对者(尽管我更喜欢[[Set]]
语义),因为它有它的好的优点。然而,它的优点并没有超过主要的缺点——我们多年来一直使用[[Set]]
语义,因为它是babel6
和TypeScript
的默认行为。
我不得不强调一下,
babel7
改变了默认行为。
私有字段
我们来看看这个提案中最具争议的部分。 它是如此有争议:
- 尽管事实上,它已经在Chrome Canary中实现,并且默认情况下公共字段可用,但是私有字段功能仍需额外开启;
- 尽管事实上,原始的私有字段提案与当前的提案合并,关于分离私有和公有字段的issue一再出现(如:140,142,144,148);
- 甚至一些委员会成员(如:Allen Wirfs-Brock和Kevin Smith)也反对它并提供替代方案,但是该提案仍然顺利进入
stage 3
; - 该提案的issue数量最多——当前提案的GitHub仓库为131个,原始提案(合并前)的GitHub仓库为96个(相比BigInt提案的issue数量为126个),并且大多数issue持反对观点;
- 甚至创建了单独的issue,以便统计总结对它的反对意见;
- 为了证明这一部分的合理性而创建了单独的FAQ,然而不够强力论据又导致了新的争论(133,136)
- 就我个人而言,几乎花了我所有的空闲时间(有时甚至是工作时间),花了大精力试图对其进行调查,充分了解其背后的局限性和决策,弄明白其形成现状的原因,并提出可行的替代方案;
- 最后,我决定写这篇评论文章。
声明私有字段的语法:
class A {
#priv;
}
复制代码
并使用以下表示法访问:
class A {
#priv = 1;
method() {
console.log(this.#priv);
}
}
复制代码
这个语法看起来违反直觉,并且很不直观(this.#priv != this['#priv']
),并且没有使用JavaScript的保留字privaye
/protected
(这可能会让已经使用TypeScript的开发者感到伤脑筋),并且为更多的访问级别的设计留下隐患。在这样的情境下,我深入的调查并参与了相关讨论。
如果这仅仅与语法形式有关,即主观审美上我们难以接受,那么最后我们或许可以忍受这样的语法并习惯它。 但是,还有一个语义问题……
WeakMap语义
让我们来看看现有提案背后的语义。 我们能够在没有新语法但是保持原有行为的情况下重写前面的示例:
const privatesForA = new WeakMap();
class A {
constructor() {
privatesForA.set(this, {});
privatesForA.get(this).priv = 1;
}
method() {
console.log(privatesForA.get(this).priv);
}
}
复制代码
顺便说一句,一名委员会成员使用这种语义创建了一个小型实用程序库,这使我们现在就可以使用私有状态。 他的目标是表明这种功能被委员会高估了。其格式化代码只有27行。
很棒,我们可以拥有硬私有
了,无法从外部代码访问/拦截/跟踪内部的字段,同时我们甚至可以通过以下方式访问同一类的另一个实例的私有:
isEquals(obj) {
return privatesForA.get(this).id === privatesForA.get(obj).id;
}
复制代码
这一切都非常方便,除了这个语义不仅包括封装
,还包括brand-checking
(您不必谷歌这个术语,因为您不太可能找到任何相关的信息)。 brand-checking
与鸭子类型
相反,从某种意义上说,它根据特定代码确定特定对象而非根据该对象的公共接口确定对象。 实际上,这种检查有其自己的用途——在大多数情况下,它们与在同一进程中安全执行不受信任的代码有关,可以直接共享对象而无需序列化/反序列化开销。
但是一些工程师坚持认为这是正确封装的要求。
尽管这是一个非常有趣的可能实现,它涉及膜
模式(简短和详尽描述),Realms
提案和Mark Samuel Miller的计算机科学研究(他也是委员会成员),但是根据我的经验,它似乎并不常见于大多数开发人员的日常工作中。
brand-checking
的问题
正如我之前所说,brand-checking
与鸭子类型相反。 在实践中,这意味着使用以下代码:
const brands = new WeakMap();
class A {
constructor() {
brands.set(this, {});
}
method() {
return 1;
}
brandCheckedMethod() {
if (!brands.has(this)) throw 'Brand-check failed';
console.log(this.method());
}
}
复制代码
brandCheckedMethod
只能被A
的实例调用,即使target符合此类的所有结构,此方法也会抛出异常:
const duckTypedObj = {
method: A.prototype.method.bind(duckTypedObj),
brandCheckedMethod: A.prototype.brandCheckedMethod.bind(duckTypedObj),
};
duckTypedObj.method(); // no exception here and method returns 1
duckTypedObj.brandCheckedMethod(); // throws an exception
复制代码
显然,这个例子是刻意设计的,并且这种鸭子类型
的好处是值得怀疑的。除非我们谈论Proxy
。 代理有一个非常重要的使用场景——元编程。 为了使代理执行所有必需的有用工作,代理包装的对象的方法应该在代理的上下文中调用,而不是在目标的中调用:
const a = new A();
const proxy = new Proxy(a, {
get(target, p, receiver) {
const property = Reflect.get(target, p, receiver);
doSomethingUseful('get', retval, target, p, receiver);
return (typeof property === 'function')
? property.bind(proxy) // actually bind here is redundant, but I want to focus your attention on method's context
: property;
}
});
复制代码
调用proxy.method(); 将导致做一些在代理中声明并返回1
的有用工作,当调用proxy.brandCheckedMethod();
而不是做一些有用的工作两次将导致抛出异常,因为a !== proxy
并且brand-check
失败了。
当然,我们可以在真实目标而不是代理的上下文中执行方法/函数,并且在某些情况下它就足够了(例如实现膜
模式),但它并非对于所有情况都是够用的(例如,实现反应式属性:MobX 5已经使用代理实现,Vue.js和Aurelia正在试验这种方法以便用于未来版本)。
通常,虽然brand-check
需要显式声明,但这并不是问题:开发人员只需选择他/她需要哪种权衡以及原因。 在明确的brand-check
的情况下,它可以以允许其与某些可信代理进行交互的方式实现。
不幸的是,目前的提案没有给予这种灵活性:
class A {
#priv;
method() {
this.#priv; // brand-check ALWAYS happens here
}
}
复制代码
如果在没有用A
的构造函数构建的对象的上下文中调用method
方法,该方法将始终抛出异常。这就是最可怕的事实:brand-check
在这里隐含并与另一个特征——“封装”混合。
虽然几乎所有类型的代码都需要封装,但品牌检查的用例数量非常有限。 当开发人员想要隐藏实现细节时,将它们混合成一种语法将导致意外的brand-check
,而为了推广这个proposal,宣传#是新的_
更是雪上加霜。
您还可以阅读有关当前提案破坏代理行为的讨论细节。 在Aurelia开发者和Vue.js作者参与其中。此外,我的评论描述了代理的几个用例之间的差异,这可能很有趣。 并讨论了私有字段与
膜
模式之间的关系。
备选方案
除非有其他选择,否则所有这些讨论都没有多大意义。 不幸的是,它们都没有达到第一阶段,因此这些备选提案没有机会得到充分发展。 但是,我想指出其中的一些,以某种方式解决上述问题。
- Symbol.private——来自其中一名委员会成员的替代提案。
- Classes 1.1 - 来自同一作者的较早提议
- 把
private
作为对象使用
结论
看起来我似乎在责怪委员会——但实际上,我没有。 我只是认为,为了在JS中实现适当的封装,已经经过多年(甚至几十年,取决于选择的起点)的努力,而我们业界更是的发生了很多变化,可能委员会错过了一些变化。导致,相关事体的优先级别可能会变得有些模糊。
不光如此,我们作为一个社区,迫使TC39更快地发布功能,但是我们却没有为早期提案提供足够的反馈,结果导致争论很多而能够用来改变某些事情的时间很少。
有观点认为,在这种情况下,该提案过程失败了。
在长期潜水之后,我决定尽我所能,以防止将来发生这种情况。 不幸的是,我做不了多少——只能写写评论文章并在babel
中实现早期提案。
总的来说,反馈和沟通是最重要的,所以我恳请大家与委员会分享更多的想法。