Loading...
 

Extern

Extern

Signature
Extern(name, File(fileName) [, overwrites(overName)] [, triggeredBy(msg1, msg2, ..., msgn)] [, provides(provider_tag) ]) [: inheritName]
Parameters
Parameters Description
name Module name
overName Name of a module that has already been Extern-statement was declared,
and its Extern-statement should now be overwritten.(see below)
fileName Name of the file to be reloaded
msg1 Message triggers reload
. . . . . .
msgn Message triggers reload
provider_tag Module exports procedures
inheritName Name of the module from which it is inherited

With Extern a module is declared whose complete definition is stored in another file. This file should only be loaded(lazy loading) when
- one of the triggeredBy() messages was sent. Of course the message also reaches the newly loaded module (see example)
- an exported procedure is called via a provider tag

If the module to be reloaded is derived from another module, the following possibilities exist:

  • Alt: Derivative and base module are defined in the same source file or #include statements ensure that they are loaded together.
  • New: Also the inheritance relation is set with the instruction Extern so that InstantView® can automatically reload the required basic modules. This approach is better because it is more flexible, as the inheritance hierarchy is defined via the Extern()-instructions can be changed easily at a central location.

The Extern-instructions for the latter case:

  Extern(name, File(fileName1), triggeredBy(msg1, msg2, ..., msgn)) : baseModName
  Extern(baseModName, File(fileName2))

// oder

  Extern(baseModName, File(fileName2))
  Extern(name, File(fileName1), triggeredBy(msg1, msg2, ..., msgn)) : baseModName

Attention: For base modules no list oftriggered messages(triggeredBy) may be specified, this is an error, because the system would then have to try to open a base module, which is not allowed as long as another module is derived from it.

There is no mandatory sequence of the Extern-instructions: The external declaration of a base module may also be used after the Extern-statement for the derived modules, because the modules are not resolved until the parser parses the actual module(Module(...)) and after the .ext file has been parsed completely (if it was specified by --extern_file ). At the latest then the base modules must all be known.

Extern Declarations are the tool to compile applications from prefabricated modules of AppsWarehouse®!

What belongs to a particular application A is determined by a sequence of Extern-instructions are defined.
A customer-specific variant of A = Application A' would be replaced by another sequence of Extern-instructions, which only differ in a few places.
Instead of the Extern-definitions for customer variant A' from scratch, the definition for A can be used and supplemented.
Two features support this possibility:

- The Extern-statements determine the module hierarchy. As soon as for a module a Extern()-statement exists, the specification of the base module within the module file(Module(...) : ...) is no longer valid. This means that you can use Extern-statement, the derivation sequence can be modified as desired. (Cycles are not allowed)
- Previously declared Extern-Statements can be redefined with overwrites.

Parameter overwrites - detailed description

The parameter overwrites() has different meanings depending on whether the own module is overwritten or another module.

Code example:

Extern(a, File(a.mod), triggeredBy(LIST_A), provides(a)) // 1. Remove provides(a), change file and add SELECT_A as trigger Extern(a, File(a2.mod), overwrites(a), triggeredBy(LIST_A, SELECT_A)) // 2. Insert new base module for a Extern(base, File(base.mod)) Extern(a, File(a3.mod), overwrites(a), triggeredBy(LIST_A), provides(a)) : base // 3. Module b takes over the LIST_A trigger and is the new provider for (a) Extern(b, File(b.mod), overwrites(a), triggeredBy(LIST_A), provides(a)) // 4. Disable module b by removing the trigger message and provider role Extern(b, File(b.mod), overwrites(b)) // 5. Restore old inheritance with no base module and readd the LIST_A trigger Extern(a, File(a.mod), triggeredBy(LIST_A), overwrites(a)) // 6. Just for demonstration: overwrite would remove the LIST_A trigger from a // even though c doesn't define the trigger Extern(c, File(c.mod), overwrites(a))

Whenever a second External() statement is written for a module, it must also contain an overwrites() for that module, otherwise it will be detected as an error, so that modules are not inadvertently overwritten. An Extern(a, overwrites(a), ...) is detected as an error if there is no Extern(a, ...) statement before. Whenever a second Extern()-If a module is written in the command, it must contain an overwrites() for that module, otherwise it will be detected as an error, so that modules are not overwritten by mistake. A Extern(a, overwrites(a), ...) is detected as an error if there was no Extern(a, ...)-statement.

Within an Extern(a, overwrites(a), ...) all specifications of the Extern() statement must be repeated which are to be valid for the module. Extern() does not work additively here. Extern(a, overwrites(a), ...) effectively deletes the previous Extern() definition for a. This also makes it possible to change or completely remove the base module for a. This mechanism is also used to "deactivate" modules, by specifying no triggeredBy and no provides, the module is no longer accessible from the outside (except by inheritance). Within a Extern(a, overwrites(a), ...)Extern()-statement that should apply to the module. Extern() does not work additively here. Extern(a, overwrites(a), ...) effectively deletes the previous Extern()-definition for a. This also makes it possible to change or completely remove the base module for a. This mechanism is also used to "deactivate" modules. By specifying no triggeredBy and no provides, the module is no longer accessible from outside (except by inheritance).

Extern(a, overwrites(b), ...) has a different semantics, because here is the intention of the developer to take over the tasks of module b with module a. For this purpose, module b is not completely replaced by a , so that modules that were previously derived from b are still there. Instead, all triggeredBy() messages and the provides() specification are removed from module b. If module a now specifies the same triggeredBy() messages and the same provides(), then module a is now delivered wherever a message or provider call previously delivered module b. Extern(a, overwrites(b), ...) has a different semantics, because here is the intention of the developer to take over the tasks of module b with module a. For this purpose, module b is not completely replaced by a , so that modules that were previously derived from b are still there. Instead, all triggeredBy() messages and the provides() specification are removed from module b. If module a now specifies the same triggeredBy() messages and the same provides(), then module a is now delivered wherever a message or provider call previously delivered module b.

Since only one overwrites() specification per External() statement is allowed, the two behaviors cannot be combined at present. Since only one overwrites() specification per Extern()-statement is allowed, the two behaviours cannot be combined at present.

This mechanism facilitates the compilation of larger applications (see example). This allows you to insert your own modules at any position within a given module hierarchy and to exchange modules.

The module specified in the overwrites() class must not yet be loaded.