In more classical languages one would initialize the library or object with the given config. Some implementations provide extensions for that, but I'd prefer to refrain from that. Other approaches are to add listeners or provide other kind of callback functions somehow. But that would also require you to maintain some kind of state in the library, which is difficult without using side-effects.
So, I think a global is easiest, like suggested by Mike. His other suggestion to pass in only one argument that provides all config/context info makes sense too. I see no reason why not to pass around an entire config element structure holding all a function might need. Kind regards, Geert -----Oorspronkelijk bericht----- Van: [email protected] [mailto:[email protected]] Namens Jakob Fix Verzonden: woensdag 28 december 2011 0:13 Aan: [email protected] Onderwerp: [xquery-talk] xquery library design Hello, I'm about to write an xquery library and I'm curious whether there are best practices around regarding the inclusion of other library modules (a quick Google search didn't turn up anything useful). In particular, I'm interested in how one would implement this: - a library module (out of several) that uses configuration data specific for each application it is used in, and that itself makes use of lower-level functions. for example, a library module with a number of publicly exposed api functions that each would take an "api_key" argument that is specific to the application and probably stored in a separated configuration file. Itself, it may make use of an http-get function defined in yet another library module. I would like to avoid the case where each function signature needs to have a required argument (the api_key and maybe others too) that could be added much more elegantly by looking up a global variable read from the configuration file. For example, for the functions documented here (http://developer.marklogic.com/pubs/5.0/apidocs/ec2-2009-11-30.html) each function has always the same three arguments that serve to identify the caller. In my case, there can be three such arguments, but only one is required. instead of this d:get-data($api_key as xs:string, $secret as xs:string?, $from as xs:string, $to as xs:string) as element(result) {}; I'd like this d:get-data($from as xs:string, $to as xs:string) as element(result) { http:get($config:url, $config:api_key, $config:secret, $from, $to) }; where the authentication arguments would be retrieved from the configuration file when necessary and added to the http get request inside the function body. so, would it be advisable to have this (where only application.xqy has all information necessary, but minimal inclusion takes place) - application.xqy that includes - configuration.xqy - library1.xqy - library2.xqy - lowlevelfunctions.xqy or rather this (where each library module is independent as it includes what's needed) - application.xqy that includes - library1.xqy which includes - configuration.xqy - lowlevelfunctions.xqy - library2.xqy which includes - configuration.xqy - lowlevelfunctions.xqy or still another scenario? sorry if that sounds confusing, Jakob. _______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk _______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
