Hello all,

I have a question about the semantics of importing base types.
Consider the below piece of TTCN-3 code. The procedure MyFunction has an
exception that returns a charstring; MyFunction is imported by another module.
Now, in this other module, to handle the exception we expect a charstring,
but...

...since charstring is a base type, it is defined in both the = importing and
the exporting module and thus, the importing module should qualify the type with
the exporting module's name as prefix, but...

...from §7.5.1 and Table 5 in the TTCN-3 standard (V2.2.1), it seems like base
types are not part of the set of importable definitions and thus *cannot* be
prefixed with an exporting module's name...

From another viewpoint, if the two modules are using different encoding
attributes set at module level, base types are either importable or downright
unusable for imported definitions, right?

So, is this TTCN-3 code correct or incorrect?

Best regards,
/Johan

Code follows below




module architecture
{
signature MyFunction(in charstring s) noblock
exception (charstring);

type port P1 procedure
{
inout MyFunction
}

type component tsi
{
port P1 p
}
}

module test_exception
{
import from architecture all

template MyFunction T1 := { s := "hi" }

testcase test () runs on tsi
{
p.call(T1);

timer t := 2.0;
t.start;

alt
{
[] t.timeout
{
log ("Timeout");
}
[] p.catch (MyFunction,charstring:*) // Is this right or wrong?
{
log ("exception caught");
}
}
}
}

On Wed, 14 May 2003, Johan Nordin wrote:

> Hello all,
>
> I have a question about the semantics of importing base types.
> Consider the below piece of TTCN-3 code. The procedure MyFunction has
> an exception that returns a charstring; MyFunction is imported by
> another module. Now, in this other module, to handle the exception we
> expect a charstring, but...
>
> ...since charstring is a base type, it is defined in both the
> importing and the exporting module and thus, the importing module
> should qualify the type with the exporting module's name as prefix, but...

No, it is known in both modules, it is defined in neither.
So, naturally, since it doesn't come from any one module, it cannot be prefixed
with a module name.

> ...from §7.5.1 and Table 5 in the TTCN-3 standard (V2.2.1), it seems
> like base types are not part of the set of importable definitions and
> thus *cannot* be prefixed with an exporting module's name...
>
> >From another viewpoint, if the two modules are using different
> >encoding
> attributes set at module level, base types are either importable or
> downright unusable for imported definitions, right?

I don't know if that's specified.
Probably the encoding of the module where the type is used 'wins'.
Remains the question whether upon importing the imported definitions don't also
get the encoding specified at module level. If so, it works.

If not, you'd have to use a subtype of the base type instead of the base type.
This, then would get its encoding from its own module and you're home free.

> So, is this TTCN-3 code correct or incorrect?

Since you don't use any encodings, it should be correct anyway.
Where should be the problem?

> Code follows below
>
>
>
>
> module architecture
> {
> signature MyFunction(in charstring s) noblock
> exception (charstring);
>
> type port P1 procedure
> {
> inout MyFunction
> }
>
> type component tsi
> {
> port P1 p
> }
> }
>
> module test_exception
> {
> import from architecture all
>
> template MyFunction T1 := { s := "hi" }
>
> testcase test () runs on tsi
> {
> p.call(T1);
>
> timer t := 2.0;
> t.start;
>
> alt
> {
> [] t.timeout
> {
> log ("Timeout");
> }
> [] p.catch (MyFunction,charstring:*) // Is this right or wrong?
> {
> log ("exception caught");
> }
> }
> }
> }
>