Perfect. Not really a problem with multiple calls to require: I run through the list when the app starts up, require each ns, then each ns calls its own "start" function at the end to configure the required hooks--all event-driven. It's never "required" again.
Thanks! On Wednesday, January 23, 2013 1:13:29 AM UTC-7, Mikera wrote: > > On Wednesday, 23 January 2013 03:47:56 UTC+8, Sean Bowman wrote: > >> I'm trying to implement a simple system to load certain namespaces into >> my application that are configurable at runtime, via a "plugins" text file >> that lists the namespaces we want to load. I have some code that loads >> this file, then line by line calls "require" dynamically, like so: >> >> (doseq [plugin plugins] >> (require (symbol plugin)) >> >> Each "plugin" namespace attaches itself to the central event bus and >> listens for events. >> >> My question is: how bad is it that I'm doing this? Am I taking any kind >> of major performance hit by dynamically calling "require" like this? >> > > Not really a problem. It's effectively the same as if you required the > namespace at the start of the program in an ns declaration. > > It requires the compilation of the namespace when it is loaded the first > time, but that isn't particularly bad and is only a one-off cost. If you > require the plugin twice then the second time is effectively a no-op. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
