[xquery-talk] xquery library design

[Geert Josten]

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: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] Namens
Jakob Fix
Verzonden: woensdag 28 december 2011 0:13
Aan: talk at x-query.com
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.
_______________________________________________
talk at x-query.com
http://x-query.com/mailman/listinfo/talk