| 04:39 | <sideshowbarker> | Is the change in https://github.com/mdn/content/pull/13229/files correct? Specifically, does handler.defineProperty() intercept Object.prototype.__defineGetter__ and Object.prototype.__defineSetter__? |
| 04:50 | <jmdyck> | Barring exceptions, __defineGetter__ and __defineSetter__ invoke DefinePropertyOrThrow, which invokes [[DefineOwnProperty]], which in a proxy is handled by the defineProperty method, so I'd say yes. |
| 04:52 | <jmdyck> | Mind you, there are a lot of things that invoke DefinePropertyOrThrow, so it might be a long list if you want to be complete. |
| 05:05 | <sideshowbarker> | jmdyck: I guess for now I won’t worry about trying to make sure it’s an exhaustive list, but will instead just accept and merge that change. |
| 11:04 | <yulia> | About the decorators proposal: I think there was a requirement introduced that if a field is decorated, its type is not changed -- which resulted in the requirement for the accessor keyword. Does anyone have a reference to that discussion? |
| 16:22 | <shu> | yulia: by type you mean "class element kind"? |
| 16:22 | <shu> | i didn't attend the discussions that hashed this out, but the requirement was introduced in response to V8 feedback |
| 16:24 | <shu> | https://github.com/tc39/proposal-decorators/issues/302, and sathya also had a doc on the previous-previous iteration: https://docs.google.com/document/d/101VnCaQaheEwSXQ_-eSAKpkutnAbDjS9T5TS2gF5zLQ/edit |
| 16:24 | <shu> | though the latter doc might be slightly out of date |
| 17:14 | <yulia> | great, thank you shu |
| 17:15 | <yulia> | One more question, this time for rbuckton -- the metadata part of that proposal, is it critical that it is within the same proposal or could we split it out the way that you had it initially? If there are documents I can look at for that you can just point me to them... |
| 17:22 | <shu> | i've had similar standing concerns about the metadata part, yes |
| 17:31 | <rbuckton> | Some mechanism for metadata is necessary for patterns such as Dependency Injection. Without a standardized approach to metadata there would be no consistent mechanism with which to store and access this information, unless the community gravitates to a single implementation. Previously, the community has gravitated towards reflect-metadata, however that approach currently depends on mutating the Reflect global to add features that would likely not be supported by TC39 since they do not directly correlate to Proxy handler operations. Having a standard mechanism for defining metadata is extremely useful for tooling, such as TypeScript's --emitDecoratorMetadata feature. That feature depends on a consistent mechanism for defining metadata, but currently leverages the non-standard Reflect.metadata method that is provided by the reflect-metadata package. |
| 18:03 | <devsnek> | if metadata means ts will give us ts type annotations as runtime information that would be cool |
| 18:03 | <devsnek> | if its just limited to decorators tho that would be sad |
| 20:26 | <ptomato> | when using the new structured headers for abstract operations, is it OK to give the type of a parameter as something like foo: a Temporal.PlainDate instance or should we stick with the wording that I'd have previously put in an assertion (foo: an Object with an [[InitializedTemporalDate]] internal slot)? |
| 20:27 | <ptomato> | as for precedent, there's one exemplar of each in ecma262: https://tc39.es/ecma262/#sec-regexpbuiltinexec vs https://tc39.es/ecma262/#sec-stringgetownproperty |
| 20:40 | <bakkot> | I would probably just say "a Temporal.PlainDate"; we do something similar with "an ArrayBuffer" and so on |
| 20:44 | <ptomato> | cool, thanks! |