GNOME Bugzilla – Bug 782186
importer: Allow the deletion of a import
Last modified: 2017-05-21 20:29:02 UTC
So that caller can force the reload of a module.
Created attachment 351120 [details] [review] importer: Allow the deletion of a import So that caller can force the reload of a module.
Example of usage: https://bugzilla.gnome.org/show_bug.cgi?id=782187
Review of attachment 351120 [details] [review]: I'm afraid this might not work as expected - you could delete the module object and reload the module, but all of the other loaded modules that referred to it would still be using the old module. ES6 modules do not support this, so I'd hesitate to make our modules diverge even more from ES6. It may arrive when Reflect.Loader is standardized though.
Yeah, you concern is easily reproducible, like this: const A = imports.moduleA; log(A); delete imports.moduleA; log(A); Here, variable A holds the old instance of moduleA. Is there anything we could do to "invalidate" the variable A so that next time it's used it will be re-evaluated? Also, even if this patch does not fix the whole issue, it indeed fixes a gnome-shell use case. Isn't this enough to give it a try?
(In reply to Jonh Wendell from comment #4) > Is there anything we > could do to "invalidate" the variable A so that next time it's used it will > be re-evaluated? Not really. You could add a private method to module objects so that, e.g. when you delete a property on an importer, you tell the module object to reset itself. But then the problem still persists one level down: const A = imports.moduleA; let myClass = A.SomeClass; delete imports.moduleA; Then myClass still refers to the old A's SomeClass. > Also, even if this patch does not fix the whole issue, it indeed fixes a > gnome-shell use case. Isn't this enough to give it a try? I'm sorry, and I can see the validity of your use case, but I am hesitating to add a feature that doesn't work as people will expect it to, and will likely also have to be retracted when we switch to ES6 modules. Is there some way to solve this inside gnome-shell itself, where you can expect extensions to be more well-behaved and not do stuff like the above code snippet?
I'm going to close this bug for now, but feel free to reopen it if you have a solution that meets the constraints discussed above.