UnloadPlugin function

This isn't so much a feature request as it is a question. Why are there LoadPlugin() and ReloadPlugin() functions, but no complementary UnloadPlugin() function? No, I can't honestly say I have a use-case - I'm just playing with yet another wrapper interface, and its absence surprised me.

Well, let's see. Plugins are supposed to be self-contained extensions. Thus plugin A shouldn't need to unload plugin B. And plugin A can't unload itself because it has the address and scripting space yanked out from under it.

In Windows for example, can Excel "unload" Word?

By that logic, LoadPlugin, ReloadPlugin, and even CallPlugin shouldn't exist either, as they disrupt the self-containment abstraction.

I think we've already established that plugins can depend on other plugins. The LoadPlugin documentation itself suggests the possibility of a "plugin manager" plugin. I'm simply following the logic: if you can load plugins, it seems odd that you can't do the inverse.


I'm not sure that's a fair comparison. Excel and Word are separate programs; they're not extensions to a common host.

(That said, I'm pretty sure it's possible to kill one process from another.)

Oddly enough, I have a use case where I want a plugin to unload itself. ^_^
I suppose I'll have to settle for just disabling it. Gee, I hope I can disable a plugin from inside itself. :\

Actually, no, disabling it just doesn't seem like it will work out. Bummer.

Why won't it work out?

Anyway, try this:

Aww, but at least give it a chance to clean up.

Wait...seriously? Hahaha. I think somehow that that won't prevent it from loading the next time. Anyway I worked out a different solution. Telling users to manually remove it instead of doing it for them.

I had the following design goals:

1) On the very first run, ask the user if they want a task to get run every time MUSHclient loads.
2) If the user chooses "yes", then run the task in question every time MUSHclient loads.
3) If the user chooses "no", then never run the task in question.
4) Don't permanently save state about the choice in the plugin itself, because there should be a way to change the decision /without/ making the user try to remember some secret command that they will quickly forget anyway because it is something they will very very rarely use.

My initial design had this completely self-contained and would just have the plugin unload itself if the user chose "no". My second design, which violates the golden design principle (haha) of keeping plugins from interacting with each other is to have the question presented by a different plugin that optionally loads this plugin if the user chooses "yes".

You want plugin X to load and as if the user wants to use the features in X? And if they say "no" X has to kill itself?

Is your big problem that, even if the plugin disables itself, it is still in the plugin list, and will show up again next time?

Added UnloadPlugin to version 4.73.

https://github.com/nickgammon/mushclient/commit/5072cd1e

I concede that if you can reload a plugin (which effectively deletes it for a while) you may as well be able to unload it without reloading it.

To be consistent with ReloadPlugin a plugin cannot itself. You would need to schedule an unload on a timer (which is what MUSHclient would have to do anyway to make that work).

Yup. And the appropriate state variable juggling to re-disable it again on next load breaks my desire #4.


Cool. :)