-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decorators and plain object properties #2519
Comments
For now I'm using a decorator that fixes this: function fixDescriptor(target, key, descriptor) {
if (descriptor.initializer) {
descriptor.value = descriptor.initializer.call(target);
delete descriptor.initializer;
}
} ... but remembering to put it in front of all properties isn't something I'm looking forward to. |
There's nothing to fix here. This is in the specification/proposal and it wont be changed unless it is there. See the javascript-decorators repo for more information. |
Could you please point me to the right place, because in the README.md file there is nothing written about plain object properties, and INITIALIZER_INTEROP.md is only concerned with classes. I've already read that spec carefully before. If you're not convinced, then maybe I'll take it to the spec so that this case will be clarified there. |
wycats/javascript-decorators#36 On Sat, Oct 10, 2015 at 9:22 PM, Rafał Ruciński notifications@github.com
|
@sebmck I've recently had a discussion with a peculiar individual in the https://github.com/wycats/javascript-decorators repo (I saw that you too commented on his rude demeanor). That reminded me of this issue, and while looking for it I also found https://phabricator.babeljs.io/T2005, an earlier issue concerning the same problem. |
I understand that when it comes to property initializers, there might be a need to perform some hocus-pocus with the
initializer
property, which effectively prevents modifying descriptor'svalue
(it is overwritten by the result of theinitializer
function in the end).But for plain objects descriptor's
value
can be left intact. Accessing it by a decorator is currently unnecessarily prevented.Could it be not so? If yes, then I volunteer to create a PR with a fix for that :)
The text was updated successfully, but these errors were encountered: