- From: <bugzilla@farnsworth.w3.org>
- Date: Thu, 29 May 2008 13:23:49 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5722 ------- Comment #1 from oliver@cbcl.co.uk 2008-05-29 13:23 ------- Consider now a module M' with the same namespace as M that also declares a variable $v. (but neither M nor M' import their own namespace) Now assume A imports M (referring to it specifically via a location hint) and B imports M'. The behaviour of a query importing A and B is implementation defined. I can see several different things to do here: 1) Import both M and M' in both A and B. In this case an error is reported because the same variable is declared in both M and M'. However the drawback with this approach is that a library can be written using variables and functions in one module, whilst importing a different module in the same namespace. When it is imported by a different query it may cease to function. 2) Import M and M' as different libraries (albeit with the same namespace) into A and B respectively. This does allow there to be two global variables with the same name and namespace, although at no point are both in scope. 3) Ignore one of the location hints. This could lead to unexpected and arbitrary behavior. 4) Treat M and M' as different libraries (that is do not allow A to have access to M', and vice versa), but raise an error if there are any variable/function collisions (but do allow both M and M' to both import another module in the same namespace) What are other implementations doing in this case? The specification could go further by specifying the following: 1) Whether the "implementation-defined set of modules that share this target namespace" is always the same set of modules for the same namespace (excluding the module doing the importing). 2) If this is not true, then whether the union of all these sets of modules can contain two variables/functions with the same name.
Received on Thursday, 29 May 2008 13:24:26 UTC