[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Module unloading
From: |
Neil Jerram |
Subject: |
Re: Module unloading |
Date: |
Thu, 26 May 2005 19:25:51 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 |
Zeeshan Ali wrote:
Hello again,
Why not use a registration
API instead? In other words, instead of this:
(define (do-plugin-thing-1 ...) ...)
(define (do-plugin-thing-2 ...) ...)
...
do this:
(let ()
(define (do-plugin-thing-1 ...) ...)
(define (do-plugin-thing-2 ...) ...)
...
(register-plugin do-plugin-thing-1
do-plugin-thing-2
...))
This is the code of the plugin right? and register-plugin is a
function provided by me for the plugins to call?
Yes, exactly.
But i'll still need
an entry point inside the plugin: a procedure that i'll call from the
module as soon as i load it. So this approach doesn't seem to be of a
big advantage.
I'm not sure I understand. Do you need to call this procedure even
before the plugin code calls register-plugin (which would happen
automatically when the plugin code file is loaded)? It's difficult to
see how there could be a requirement for this, given that it is
impossible to separate the loading and the register-plugin call.
If it is OK to call this procedure after register-plugin has been
called, then the procedure to call could be another argument to
register-plugin:
(register-plugin init-proc
do-plugin-thing-1
do-plugin-thing-2
...))
I think I have figured-out a way out of this visibility problem:
(define amodule (resolve-module '(amodule)))
((variable-ref (module-local-variable amodule 'xchat-plugin-init)))
This code seems to work and there is no need for the plugin to
export it's objects anymore.
Yes, this would be fine.
Also, this way you could stay
pure-R5RS if you like, as you don't really need any features of the
module system.
Wait a sec? Are you really thinking what i think you are thinking:
use the simple 'load' procedure combined with your suggested
registeration API instead of using the module system of guile?
Yes. It may indicate a deficiency in the module system, but I don't
think that modules are currently especially well aligned with the
requirements of acting as a plugin. In my view modules are mostly
useful (and work very well) for organizing the code of a non-trivial
application (and with a thought of identifying and grouping together the
code that might be reusable by other applications).
To map this onto your program, I think it would be absolutely fine to
use just load to load plugins - in fact this would work well with a
standard File Selector GUI: "Browse for plugin ...", whereas for a
module-based invocation you'd need to invent a new dialog. Please note
that, even when a file is loaded using plain "load":
1. The plugin author can still choose to make their file a module, if
that is of use to them, by beginning it with a (define-module ...) form.
2. The plugin author can still choose to use modules to organize their
plugin code internally, by splitting out some of the code into modules
and using (use-modules ...) from the main file to load them.
3. The plugin author can still use third-party modules, using
(use-modules ...).
Regards,
Neil
- Re: Module unloading, (continued)
- Re: Module unloading, Neil Jerram, 2005/05/24
- Re: Module unloading, Rob Browning, 2005/05/24
- Re: Module unloading, Neil Jerram, 2005/05/26
- Re: Module unloading, Rob Browning, 2005/05/26
- Re: Module unloading, Neil Jerram, 2005/05/26
- Re: Module unloading, Zeeshan Ali, 2005/05/24
- Re: Module unloading, Zeeshan Ali, 2005/05/24
- Re: Module unloading, Zeeshan Ali, 2005/05/26
- Re: Module unloading, Neil Jerram, 2005/05/26
- Re: Module unloading, Zeeshan Ali, 2005/05/26
- Re: Module unloading,
Neil Jerram <=
- Re: Module unloading, Zeeshan Ali, 2005/05/26