On 6/13/05, David Carlisle <davidc(_at_)nag(_dot_)co(_dot_)uk> wrote:
A compiled module will need to be defined as something more closed. It
may be a collection of many compiled stylesheets. What is important is
its property that it doesn't use/know about global objects that exist
outside this module (such as global variables, keys, etc). The only
way to pass information to this module is by using parameters.
would you also ban references to functions (or non-core functions) not
defined in the module?
This will only be needed if the referenced non-core functions cannot
be included/imported at the time of the compilation of the module.
Something like that would appear to be needed if
you want to compile-time type-check expressions that involve function
calls.
Yes.
It is still possible, however to manipulate nodes (template
references) without having to know in advance the templates (and their
signature) that will match the node at run time.
As with FXSL, the type-checking can be done at run time.
In general whatrules would you envisage for all global name resolution;
both for references within the compiled stylesheets and for references
in the calling stylesheet to constructs defined in the compiled
stylesheet?
There are different possible design decisions. The client of a
compiled module should have a mechanism to access the type definitions
of global objects in the compiled module. Producing these may be a
separate option when running the XSLT processor.
The XSLT processor will check at compile time that the client of a
compiled module communicates with the objects (functions) of the
compiled module only using the allowed parameter types.
The reverse -- to check within the compiled module the types used by
its client in passing template reference parameters to its functions
-- will not be possible during compile time. Run-time type checking
will still be possible.
Cheers,
Dimitre Novatchev
Wouldn't you need some analogue of import precedence for all kinds o
objects, templates, functions, variabes, etc?
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--