|
Multiple modules
As our application grows, we may want more modules for other
functionality. No problem: check 'em in the lib and add 'em to the
<USES>
directive in our example
application:
<USES lookfeel shopcart creditcard>
|
Indirect includes
Modules can even use each other; the creditcard
module
above might use a cctools
module for low-level functions. It
would simply have a <USES cctools>
directive.
Our top-level example
script would then indirectly depend
on any changes to cctools
, even though the programmer doesn't
realize it. No problem: automatic dependency checking will cover
that, and re-compile example
if such an indirect module
changes.
Overly complicated includes
Certain combinations of module syntax are disallowed in Vortex to
avoid possibly erroneous or confusing situations. For example,
Vortex insists that the entire code base for an application be of
the same date level - all modules be the same date. This means that
the DATE
attribute to to USES
is only allowed once, and
only in the top-level application. Otherwise, two modules could try
to include different revisions of the same third module - functions
would clash. And the top level app developer - who is most
important - would never know what mysterious combination of dated
code his modules are including beneath him. "Fallback" would be
impossible, and auto-dependency checking might not work.
For similar reasons, a specific revision number cannot be given
in USES
: it would only be correct for one module, and may be a
different date or even nonexistent in another module.
Branching revisions, ala RCS, are also not supported: if the
revision list for a module gets that complicated, it's time for a
new module, not a complicated tree branch.
|