[Bug 1998] Inconsistency wrt module import new text

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1998





------- Additional Comments From jmdyck@ibiblio.org  2005-10-01 23:49 -------
(In reply to comment #8)
>
> In answer to the question he poses (why allow more than one module per ns?)
> the short answer is because function namespaces and physical partitioning
> have nothing to do with one another.

(If that were true, then in addition to multiple modules implementing a single
namespace, you could also have a single module implementing multiple namespaces.
But that's beside the point, I think.)

> If your only choice is between putting all
> 20000 lines of XQuery into a single file or inventing random distinct namespaces
> just so you can partition the physical file (which will drive all the clients
> of that module completely spare trying to remember which function is in which
> namespace), you have no sane solution to a basic development issue.

Right, and if the Comment #5 wording is adopted, and you want portable code,
that choice *is* your only choice, so you have no sane solution to the issue.

> The current design also has the salutary effect of allowing one to hide all 
> the "internal functions" in one physical file, have a "api library" import that
> set, and only advertise the api library to the world. Thus: function export, 
> without any special mechanism for function export.

If the api module and the internal module have the same target namespace, then
importing that namespace isn't guaranteed to import the api module only:

-- it might (and under the prior semantics, it would) import both modules, in
which case the internal functions wouldn't be hidden; or

-- it might import only the internal module, in which case the client code
(using only the functions defined in the api module) would break.

Received on Saturday, 1 October 2005 23:49:36 UTC