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 nbsp;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.