搜索词
hard privacy #31670
建议
允许创建 hard privacy ,就像我们在 private 中所做的那样。
用例
示例
允许使用 constructor(#foo: number) {} 或 constructor(private #foo: number) {} 或 constructor(hard private #foo: number) {}
与
#foo: number;
constructor(foo: number) {
// This works.
this.#foo = foo;
}class C {
constructor(#foo: number) {}
log() {
console.dir(this.#foo);
return this
}
}
let o = new C(777).log();
// error
o.#foo;相同
class C {
#foo: number;
constructor(foo: number) {
// This works.
this.#foo = foo;
}
log() {
console.dir(this.#foo);
return this
}
}
let o = new C(777).log();
// error
o.#foo;检查清单
我的建议符合以下准则：
- 这不会对现有的 TypeScript/JavaScript 代码造成破坏性更改
- 这不会改变现有 JavaScript 代码的运行时行为
- 这可以在不根据表达式的类型发出不同的 JS 的情况下实现
- 这不是一个运行时特性(例如库功能、带有 JavaScript 输出的非 ECMAScript 语法等)
- 这个特性将与 TypeScript's Design Goals 的其他部分保持一致。
4条答案
按热度按时间wqsoz72f1#
我同意这个想法，并曾在之前为此进行过论证。
在我们的代码库中，我们广泛使用了带有构造函数参数简写形式的"private"关键字。我们希望将代码迁移到使用硬私有字段。不支持在所有相同位置的软私有，这会使得语言变得复杂，降低其直观性和一致性，并使迁移变得更加困难。顺便说一下，我们也赞赏构造函数参数字段简写带来的小内存占用，并且非常遗憾地失去它。特别是对于DI框架的消费者(我们使用的是Angular),失去它意味着增加了大量的代码膨胀。
eit6fx6z2#
当前，TypeScript允许在类中使用
contructor(private readonly text: string) {}自动分配生成的构造函数内的this.text,因此自然地，constructor(readonly #text: string) {}会自动分配生成的构造函数内的this.#text。这也允许在现有字段初始化器存在于构造函数的情况下，以最小的TypeScript源代码更改为重构函数更改
private text为#text。这是不可能的，这有点令人惊讶，因为它增加了从仅包含TypeScript的概念到原生JavaScript功能的重构摩擦，并添加了一个偏好偏差，以保持使用
private field而不是#field,而TypeScript的设计目标是保持与干净的JavaScript接近。注意：本提案提到了
private #field,这应该是不可能的，因为原生私有字段无法从当前类范围之外引用，因此它们不能具有访问修饰符(甚至不是protected)。@bluelovers,你是否考虑改变这一点？ds97pgxw3#
我也可以投这个票吗？
dphi5xsq4#
哦，我能看到一个原因这可能会很难：
所以问题是，你不能访问本地是否重要?它可以被省略掉吗？即使在构造函数中，你也必须使用
this来访问它。