Hi Stephen,

thanks for your thoughts.

Am 04.07.2009 um 16:19 schrieb Stephen C. Gilardi:

Is there some specific reason for that or could load be adapted to also return the last value evaluated?

I experimented with this, got it to work for a simple case, and prepared my initial reply below. In working with the idea some more though, I think there is a show-stopper problem with it. In the case of an AOT compiled Clojure file, it's loaded (ultimately) with Class.forName. I don't see a way to retrieve the last eval'd expression from such a load.

Ok. That would of course be too much buck for the bang.

For the case you described, I recommend the method I described below: require the plugin file to define a function with a well- known name in its namespace and call that function after loading the plugin.

That was the other way, I considered. I think, requiring plugins
to be on the classpath is not really an option, this it would make
the application too static. But having a similar convention for
the plugin nameing as for namespaces, that would probably
be sufficient for load-reader. I think, I will change my implementation
to work like that.

Also, clojure.core/load currently supports loading multiple libs with one call, but apparently that's never used in clojure.core or clojure.contrib. Changing its signature to accept only one lib name would facilitate returning a value. I did that in my experiment and all tests still pass.

Aargh. Hadn't thought of that. You are right. In fact I load several
files with one load, in several of my projects.

In the case you describe, I think it would be clearer to require that your plugin files define a function with a specified name (like "plugin-info") that can be called after they are loaded to return the info you require. This would be similar to having Java plugins implement a "de.kotka.Plugin" interface (for example). This would make your intention for these files explicit both within their body and in your plugin loading code.

Yes. This is the right way to go. However I was a bit concerned
about the nameing. I don't want to have to specify the file *and*
the namespace. But with a plugin nameing convention (read
"the usual namespace nameing convention") this is not really
a problem, I guess.

Sincerely
Meikel

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to