- From: <bugzilla@jessica.w3.org>
- Date: Tue, 21 Dec 2010 18:44:36 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10863
Michael Kay <mike@saxonica.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mike@saxonica.com
--- Comment #2 from Michael Kay <mike@saxonica.com> 2010-12-21 18:44:36 UTC ---
If modules A and B both make calls on UTIL, then they both need to import UTIL,
because our rules say that import is not transitive. It's therefore very
unlikely that any implementation would report this as an error: I think your
statement that this is the "status quo" is wrong. Where you might get an error
is if they import UTIL from different locations, such that the system cannot
detect that A and B are importing the same thing.
I think we surveyed a number of implementations and decided that the majority
gave you one instance of the variable; but there were some implementations,
particularly those that allowed separate compilation of modules, where you got
two separate instances. This is why the text is framed as it is. I think it
would be better to be more prescriptive and insist that there is only a single
instance, at least in the case where the variable is declared public. It's less
clear that this is the right answer if the variable is private.
For information, XSLT 3.0 (which will introduce support for separate
compilation) is heading down the route of saying that each "package import"
gives you a separate instance of the global variables. That's necessary because
in XSLT the importer can override definitions in the importee, and therefore
two different importers can override the same definition in different ways.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 21 December 2010 18:44:38 UTC