Reflective API for Adding Class Properties

[sebmarkbage]

There is an object that represents the class properties that were defined declaratively.

It seems like it is also possible to add new properties for initialization using this API:

Object.defineProperty(
  MyClass[Symbol.classProperties],
  'foo',
  {configurable: true, enumerable: true, writable: true, value: function() { return 123; }}
);

Could you clarify that it is not just for reading but also creating properties?

[jeffmo]

Sure, clarified in https://github.com/jeffmo/es-class-properties/commit/1092b65aed70e5ce9c4fad90f68a534db635b951.

I can think of plenty of hypotheticals where this will be useful, but do you have any concrete use cases in mind that I might cite as well?

[domenic]

What happens if I do this to Object[Symbol.classProperties] or HTMLElement[Symbol.classProperties]? Similarly for Object.prototype and HTMLElement.prototype.

[jeffmo]

@domenic: Out of the box there shouldn't exist any Object[Symbol.classPropeties] (which you've made me realize I need to address explicitly in the spec text).

Is your question asking what would happen if someone added one? If so, the answer is that it would affect [[Construct]] behavior of Object() and HTMLElement just as it does for other classes.

@wycats also suggested that we add something like a Function.defineField() (name not withstanding) and Function.getOwnFields() that store/read into/out of slots (rather than via a hanging property). I don't see strong benefits in either direction (except that Symbol.classProperties is slightly simpler to spec), but perhaps one benefit of using slots is that we don't have to deal with the conditional availability of this dangling properties container.

[domenic]

Yes, using slots addresses #4 much better.

I think it is pretty bad that you could affect the behavior of built-ins using this. You'd get to run code every time an object is created. For HTML elements at least that's explicitly a no-go per recent web components spec discussions.

It seems better to leave to reflective side of things out at this point.

[jeffmo]

I think it is pretty bad that you could affect the behavior of built-ins using this

No built-ins will be using this from the start -- so it shouldn't affect any of them unless those builtins are explicitly modified by the user to do so. In that case, however, it's not really any worse than modifying built-in prototypes.

[domenic]

My point is exactly that it's much worse than modifying built-in prototypes.

[jeffmo]

Let's consolidate the discussion over at #4