Dear colleagues !

Some remarks concerning Modules and their parameterization :

1)
From the point of professional language design a thing called
"module with parameters" which can only be instantiated ONCE (i.e. with
one distinct combination of actual parameter values) is a
contradictio in adjecto.

Not only the testing community (regarding e.g. ASN.1 syntax experiences
etc.) but also language design and compiler construction have a
30-year-experience, -- and this with a little more theoretic foundation, I
dare to say ...

So if you try yourself in language design you should at least have a look
at the results of these efforts.


2)
I thought TTCN-3 shall be a language to support testing and specification
for a somehow *longer* period of time.
Without a sane concept of modularity these things (you call "modules")
CANNOT BE USED FOR ABSTRACTION in a wider field of application.

Even if you cannot imagine today how abstraction can be useful in
testing, I promise that a lot of all those users which will
(hopefully) explore the possibilities of TTCN-3 in a deeper fashion
will bitterly complain (or be amused) that such a basic feature is not
supported.

In contradiction I would strongly advise to additionally include TYPE
EXPRESSIONS into the list of possible module parameter types, -- this is
what modern techniques of genericity require, and this is what you
soon will come accross to be very, very useful.

3)
The idea of imposing a *global* restriction on all module instantiations
induced by the main module hides the principle of information hiding
and therefore is non-professional.


4)
The argmument that you do not want to change a single syntax rule
(resp. add a new construct, as in Baltasars proposal) seems rather
astonishing w.r.t. the many changes which happened in the last weeks.

Do you really want to loose the fundamental feature of CODE REUSABILITY,
which (a) would increase the power of TTCN-3 significantly (in the
future!), and (b) which is indeed not really an issue in implementation ?

Regards
Markus



=======================================================================
|\ /| Markus Lepper
| \/ | TU Berlin - FB13 - Uebb Raum FR5023 Tel +49 30 314 24890
| | daheim Wigstr. 7 - 45239 Essen Tel +49 201 49 25 78
===== \-+--- ===========================================================
\|

On Fri, 19 Oct 2001, Jens Grabowski wrote:

> Hi together,
>
> I like also to add some comments to the discussion about the IMPORT problem.
>
> The original problem is that the module paramters (and their values) of the
> module
> from which we like to import a certain definition is bound to the definition
> itself.
> This has the following two negative effects:
> - lots of writing if the same module parameter is needed in several import
> statements.
> - possible inconsistencies if different values are assigned to the same
> module
> parameters in different import statements.
>
> We can now either try to tackle one problem or both. We would like to tackle
> both
> but I am not sure that we can reach this goal. Of course, the inconsistency
> problem
> is the most important problem and the simple solution is:
> - keep everything as it is, and
> - add a consistency rule that disallows the assignment of different values
> to the same
> module parameter. This consistency rule can be checked statically by a
> TTCN-3 compiler
> (Btw. this is a proposal from Johan Nordin from Telelogic).
>
> Another possibility is of course to remove the parameter assignment from the
> import
> statements and do it in some central place. This basically is the proposal
> from Zoltan
> (Ericsson) and this is also the way the problem is solved by the module
> instance
> proposal, or in other words: module instances are a new concept but only
> solve our
> second problem due to the central instantiation of the module, i.e., on a
> syntactical level.
>
> The problem we have with Johan's proposal is that it does not solve the
> problem of
> repeating identical module parameter assignments in several places.
>
> The problem we have with Zoltan's proposal is that we would like to keep a
> module
> self-contained, i.e., everything needed for executing the module should be
> within the module.
>
> The problem we have with module instances is that it is a new concept and
> beyond
> a 'powerfull-and-nice-to-have-feature' argument, we do not see an urgent
> need for such a
> 'powerful-and-nice-to-have-feature' for a TESTING language.
>
>
> Our proposal tries to tackle both problems (unnecessary writing and
> inconsistencies)
> without introducing too much new syntax and without changing the concept.
> This means:
>
> a) the assignment of parameters is removed from individual import statements
> b) the import of several definitions is grouped.
>
> However, as Thomas has pointed out, we need consistency rules if we allow to
> distribute the imports from one module in several parts of the definition
> part. But we
> believe that these rules are easier and more intuitive than rules on import
> statements
> for individual definitions.
>
> The reason for allowing the distribution of import statements in several
> parts of the
> module definitions part was to keep flexibility in the style of writing a
> module, e.g.,
> someone may collect all import statements at one place someone else likes to
> place the import statements near the definitions where the imported
> definition is used.
>
> However, at the moment I am more in favour to remove the flexibility of
> distributing
> import statements from the same module and to force the user to make the
> import
> of all definitions from another module at one place. This means I am in
> favour
> to keep our syntax proposal for import, but only allow one import definition
> for
> each module from which we like to import.
>
> I believe that it would be simple to extend the syntax if it turns out that
> the module
> instance concept really is needed.
>
> I also believe that this solution is inline with Zoltan's proposal, because
> - we do not change the concept
> - we remove the parameter assignment from the individual definitions to be
> imported and
> - basically we move the information from the proposed configuration file
> back into the
> module.
>
> The drawback is of course that the syntax for the import statement has to be
> changed.
>
> Hope that helps to clarify things.
>
> Best Regards
> Jens
>