W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2004

visibility of declarations in sibling module resources

From: Per Bothner <per@bothner.com>
Date: Thu, 12 Aug 2004 11:49:51 -0700
Message-ID: <411BBBCF.4060508@bothner.com>
To: public-qt-comments@w3.org

Are variables and functions declared in a module resource
visible to other module resources in the same library module?

According to my reading of the specification, the answer is "no".
Is that the intent?  It is not possible to import other module
resources of the current module.

Note that "fixing" the specification so that a module resource
implicitly imports other resources in the same module may be
problematical.  Separate compilation of a library resources
becomes problematical in any implementation that makes use of
compilation hints.  It can't find the other resources, unless
all of the resources are compiled at the same time.  At which
point one asks:  What is the use case for module resources?

Suggestion: Replace "module resources" by a texual include
mechanism.  There is a need for a textual include mechanism,
since one may want to share namespace declarations and scheme
imports.  At the same time, a texual include mechanism also
allows for defining a library module using multiple "resources".

ModuleResource ::= Prolog
LibraryModule ::= ModuleDecl Prolog

Prolog := Include | ...
Include := "include" StringLiteral Separator
ModuleImport :=
   "import" "module" ("namespace" NCName "=")? StringLiteral
      ("at" StringLiteral)?

An "include" names a ModuleResource using a URI.  The URI is
typically relative, but it is resolved in an implementation-defined
manner.  The included resource must have the syntactic form of a
Prolog, and it is processed is if texually copied into the
current resource.
	--Per Bothner
per@bothner.com   http://per.bothner.com/
Received on Thursday, 12 August 2004 20:20:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:20 UTC