Task overriding broken in 0.7.11
See original GitHub issueIn 0.7.10, overriding a task definition in an extend
call worked as I’d expect a normal property override to, but with the getter changes in 0.7.11 it now throws TypeError: Cannot set property go of [object Object] which has only a getter
.
const MyThing = Ember.Object.extend({
go: task(function*() { return 'yes'; })
});
const MyOtherThing = MyThing.extend({
go: task(function*() { return 'actually, no'; })
});
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
BuildBot Manual 0.7.11
Each build can have its own branch (the category–branch–version string) to override the default, as well as a revision number (which is turned...
Read more >linkedin-gradle-plugin-for-apache-hadoop/VERSIONS.md
LIHADOOP-24729 Addressed improper console output for azkabanExecuteFlow task; Fix jline dependency override in hadoop-plugin from azkaban-client subproject.
Read more >Bug listing with status RESOLVED with resolution TEST ...
Bug:233 - "Emacs segfaults when merged through the sandbox." status:RESOLVED resolution:TEST-REQUEST severity:critical · Bug:3888 - "yenta_socket module not ...
Read more >What's New in Beaker 24?
A task can report this result to Beaker in the same way that it reports Pass, Fail, or Warn using the standard rhts-report-result...
Read more >npm fails to install - Google Groups
1265 silly resolved description: 'The JavaScript Task Runner', ... of `0.3.0` the Riak transport has been broken out into a new module: [winston-riak][17]....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Just adding a no-op
set
trap seems to fix this:This looks like it shouldn’t work (this line, in fact, has no effect with this setter) but it nonetheless causes a test case to pass. As far as I can tell, thanks to Ember delegating to the descriptor’s
setup
method here, the descriptor ends up properly set/reset when overridden.I have this change and test case on a fork. I don’t mind opening a PR for review with the caveat that I don’t fully grok the Ember property mechanisms involved, which is not a feeling I like when submitting code.
I believe @camhux is correct. ember-metal does a property set when merging mixins, so we have write an empty setter so that things don’t below up. I’ve implemented this in #83