【新提案】增加运行时获取class field的手段

[LongTengDao]

目前，不parse ast是无法获知class A { a; b; }中field的列表的。运行时它的开销很大，而且也无法解析结果（如果field是一个计算属性）。这限制了框架设计的能力。

方案1：Function.getClassFields(class{a;}) //['a']
方案2：(class{a;})[Symbol.classFields] //['a']
方案3：Reflect.getClassFields(class{a;}) //['a']

个人认为，第一个方案似乎比较好

[ljharb]

What's the use case where you need to know what class fields a class has?

In this example:

class X {
  a;
  constructor() {
    Object.defineProperty(this, 'b', {});
  }
}

Why do you need a list that contains "a" but doesn't also contain "b"?

[LongTengDao]

class是做组件的极佳粒度的编程单位，人们设计的框架可以对其将要定义的fields进行高效的预检查，甚至优化后续行为。

而动态defineProperty的行为，通常意味着用户选择放弃内部优化、有意进行绕过来达到hack的目的。

[ljharb]

Can you be a bit more concrete? It's an intentional part of the design imo that a and b in X aren't distinguishable.

What specific optimizations do you expect are possible here for a that aren't for b?

[LongTengDao]

field: static check & optimize & typing
defineProperty: x x x

class A { a; }
class B { a; }
const C = mixin(A, B);// silent bug -> easy to warn

[ljharb]

Using a "mixin" pattern (which I think is a very bad idea, but that's an entirely separate debate) always risks collision. If you're using a type system, then it'd be caught with both a and b in class X above, because you'd need to explicitly add the type for b.

If you're not using a type system, simply because a constructor could add anything it wants, you can't actually know from the constructors what shape changes they'll apply - which means that the only way to detect it is to actually invoke the code (construct an A and a B) and introspect the instances for own properties.

[XGHeaven]

首先你没法保证开发者是否使用了 babel 等编译工具，一旦使用了，这个能力就会完全丢失。
其次我感觉你的场景下为什么不用装饰器呢？如果你是想做校验这些能力的话，ts 的装饰器用 metadata 一样可以实现效果。而且还兼容各种产物。

[LongTengDao]

额，当然可以，因为es装饰器总盼不来，ts的装饰器就也不敢用……装饰器毕竟太复杂，这个后发先至的可能性还是有的吧……

（不只是校验，还有做reactive api的封装等，这个需求感觉比装饰器那一大坨别的功能尖锐）