After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782186 - importer: Allow the deletion of a import
importer: Allow the deletion of a import
Status: RESOLVED WONTFIX
Product: gjs
Classification: Bindings
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks:
 
 
Reported: 2017-05-04 21:27 UTC by Jonh Wendell
Modified: 2017-05-21 20:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
importer: Allow the deletion of a import (962 bytes, patch)
2017-05-04 21:27 UTC, Jonh Wendell
needs-work Details | Review

Description Jonh Wendell 2017-05-04 21:27:32 UTC
So that caller can force the reload of a module.
Comment 1 Jonh Wendell 2017-05-04 21:27:36 UTC
Created attachment 351120 [details] [review]
importer: Allow the deletion of a import

So that caller can force the reload of a module.
Comment 2 Jonh Wendell 2017-05-04 21:30:19 UTC
Example of usage: https://bugzilla.gnome.org/show_bug.cgi?id=782187
Comment 3 Philip Chimento 2017-05-05 04:31:03 UTC
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.
Comment 4 Jonh Wendell 2017-05-09 18:20:51 UTC
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?
Comment 5 Philip Chimento 2017-05-10 04:08:36 UTC
(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?
Comment 6 Philip Chimento 2017-05-21 20:29:02 UTC
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.