[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

    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 init-proc

    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 ...).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]