Hi,

there is another discussion thread that I would like to start:

Would it make sense to add (structural) inheritance of component types
to TTCN-3?

What I mean by this is a mechanism to take a component type and base a
new component type on it:

type component A {
timer T;
port PCO p;
var integer x
}

type component B : A {
timer T1;
port PCO1 q;
}

would for example yield a component type B that declares the same
members as A plus those in the definition of B.

What would be the benefit of such a mechanism? Well, it would make it
considerably easier to write re-usable 'library-like' code that requires
reference to a component type.

For example, implementing a component synchronization mechanism based on
a control port located at these components. This would require defining
a suitable port type 'ControlPort' and component type
'ControlledComponent'. All 'library' functionality that deals with the
synchronization issues could be put into functions and alt steps
'running on' ControlledComponent. This is already possible today.

Now, how doe we re-use such a functionality today? We copy the
ControlledComponent members into out component and rely on the type
compatibility rules to ensure that everything that 'runs on'
ControlledComponent also 'runs on' our such derived component.

Needless to say that copying code is never a nice thing. What, e.g.,
happens when an additional member needs to be added to
ControlledComponent? Right - each 'derived' component type needs to have
the additional member added also. Not good.

The inheritance mechanism would avoid such problems. It would also not
add additional demands on the run time environment because each
inheritance can be rolled out at compile time. Of course, one would need
to think about issues like multiple inheritance and what to do in terms
on name clashed between ancestors and children, but all these seem
controllable issues to me.

What do people think about such a feature?

BR

Stephan Tobies

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi Stephan,

What you are proposing is something similar to the ASN.1
COMPONENTS OF xxx. Your idea sounds good.

Introducing OO concepts such as inheritence was avoided (as much as possible) in
TTCN-3 to keep it simple and avoid huge changes. I personally have no aversion
to OO concepts or
features, if it makes sense and provides overwhelming practical
advantages, AND does not make implementation of a compiler/translator
significantly more difficult.

Adding multiple inheritence features will affect those who have
chosen to implement a TTCN-3 to language XXX which do not support OO.


>type component A {
> timer T;
> port PCO p;
> var integer x
>}
>
>type component B : A {
> timer T1;
> port PCO1 q;
>}
>

Could you not have:

type component A {
timer T;
port PCO p;
var integer x
}

type component B {
components of A;
timer T1;
port PCO1 q;
}
which is similar. The OO syntax you propose is neater.
Maintenance issues which you point out are also neatly taken
care of.


Cheers,

Claude.


>Hi,
>
>there is another discussion thread that I would like to start:
>
>Would it make sense to add (structural) inheritance of component types
>to TTCN-3?
>
>What I mean by this is a mechanism to take a component type and base a
>new component type on it:
>
>type component A {
> timer T;
> port PCO p;
> var integer x
>}
>
>type component B : A {
> timer T1;
> port PCO1 q;
>}
>
>would for example yield a component type B that declares the same
>members as A plus those in the definition of B.
>
>What would be the benefit of such a mechanism? Well, it would make it
>considerably easier to write re-usable 'library-like' code that requires
>reference to a component type.
>
>For example, implementing a component synchronization mechanism based on
>a control port located at these components. This would require defining
>a suitable port type 'ControlPort' and component type
>'ControlledComponent'. All 'library' functionality that deals with the
>synchronization issues could be put into functions and alt steps
>'running on' ControlledComponent. This is already possible today.
>
>Now, how doe we re-use such a functionality today? We copy the
>ControlledComponent members into out component and rely on the type
>compatibility rules to ensure that everything that 'runs on'
>ControlledComponent also 'runs on' our such derived component.
>
>Needless to say that copying code is never a nice thing. What, e.g.,
>happens when an additional member needs to be added to
>ControlledComponent? Right - each 'derived' component type needs to have
>the additional member added also. Not good.
>
>The inheritance mechanism would avoid such problems. It would also not
>add additional demands on the run time environment because each
>inheritance can be rolled out at compile time. Of course, one would need
>to think about issues like multiple inheritance and what to do in terms
>on name clashed between ancestors and children, but all these seem
>controllable issues to me.
>
>What do people think about such a feature?
>
>BR
>
>Stephan Tobies
>
>--
>Stephan Tobies Sr. Research Engineer, Nokia Research Center
>~ Mobile Networks Lab, Protocol Engineering Group
>E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Work Phone: +49-234-9842262
>Fax: +49-234-9843491
>Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>


--
Claude Desroches email:CDesroche@aol.com
Conformance Technologies Ltd. phone: +49 30 9606 7986
685 Cedar Point Road fax: +49 30 9606 7987
Penetanguishene Ontario, mobile 0174 701 6792
Canada

ext Claude Desroches wrote:

>Hi Stephan,
>
>What you are proposing is something similar to the ASN.1
>COMPONENTS OF xxx. Your idea sounds good.
>
>Introducing OO concepts such as inheritence was avoided (as much as possible)
in TTCN-3 to keep it simple and avoid huge changes. I personally have no
aversion to OO concepts or
>features, if it makes sense and provides overwhelming practical
>advantages, AND does not make implementation of a compiler/translator
significantly more difficult.
>
>

Actually, one could even go as far to make the compiler significantly
more simple when component type compatibility would only be defined via
inheritance. Currently, behaviour that 'runs on A' can be executed on
component type B when B has at least the same members as A of the same
types. Checking this is rather diffecult and requires expensive
comparison of the types. When the condition would be replaced by 'if B
is derived from A' the type checking would be much simpler - although
this would not be backward compatible.

>Adding multiple inheritence features will affect those who have
>chosen to implement a TTCN-3 to language XXX which do not support OO.
>
>

The inheritance can be unrolled at compile time and does not necessarily
have to be captured by inheritance in the target language. We are
talking more or less about 'interface inheritance' and I think that it
would make sense to allow multiple inheritance when we ensure that there
are no name clashes between the parent component types.

Of course, one could also devise a 'naming scheme' that would allow to
deal with clashes upong multiple inheritance. I am just thinking out
loud here:

type component A {
timer T := 1.0;
}

type component B {
timer T := 10.0;
}

type component C : A,B {
timer T := 100.0;
}

This could yield a component with 3 separate timers: A.T, B.T, and C.T.

When used in a context of 'A', only A.T is known and is implicitly
refered to by 'T':

function f() runs on A {
T.start;
T.timeout; // after 1 second
}

When we are in the context of C, then we would get:

function g() runs on C {

T.start;
T.timeout; // after 100 s

B.T.start;
B.T.timeout; // after 10 s

A.T.start;
A.T.timeout; // after 1 s
}

I am not entirely sure that this would be a good idea, though. Probably
that would make things too complicated. Opinions?

> [snip]
>
>
>Could you not have:
>
>type component A {
> timer T;
> port PCO p;
> var integer x
>}
>
>type component B {
> components of A;
> timer T1;
> port PCO1 q;
>}
>which is similar. The OO syntax you propose is neater.
>Maintenance issues which you point out are also neatly taken
>care of.
>
>

I really do not care that much, how inheritance should be expressed. But
the ':' notation collects the information from which component types the
type inherits at an exposed position. This is not really the case with
the component of notation. What I would not like to see is the
invention of yet another keyword!

BR

Stephan
--

Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi Stephan,

Thanks for the comments.

>ext Claude Desroches wrote:
>
>>Hi Stephan,
>>
>>What you are proposing is something similar to the ASN.1
>>COMPONENTS OF xxx. Your idea sounds good.
>>
>>Introducing OO concepts such as inheritence was avoided (as much as possible)
in TTCN-3 to keep it simple and avoid huge changes. I personally have no
aversion to OO concepts or
>>features, if it makes sense and provides overwhelming practical
>>advantages, AND does not make implementation of a compiler/translator
significantly more difficult.
>>
>>
>
>Actually, one could even go as far to make the compiler significantly
>more simple when component type compatibility would only be defined via
>inheritance. Currently, behaviour that 'runs on A' can be executed on
>component type B when B has at least the same members as A of the same
>types. Checking this is rather diffecult and requires expensive
>comparison of the types. When the condition would be replaced by 'if B
>is derived from A' the type checking would be much simpler - although
>this would not be backward compatible.
>

At this stage, to what extent is backwards compatibility important?

Granted, backwards compatibility is an issue, but TTCN-3 is
still quite new. The number of internationally or nationally standardized ATSs
written in TTCN-3 can be counted on one
hand (two hands???). If the changes you are proposing make everyone's lives
easier, that is, test implementors, as well as tool manufacturers, then these
should be seriously considered for adoption into the next increment of TTCN-3
(TTCN-3++)???.

Mind you, one might need to look at such impact from a vendor point of view
also. That is, if potential customers learn that multiple inheritance is going
to be adopted, many will likely delay their purchase of tools until the standard
is stable and vendors have implemented this. Then again, some sort of migration
path solution might be offered to these customers.

Alternatively, one might consider having two versions of
TTCN-3:
-the non-OO variant and
-the OO variant,

one for each class of customer. Then again, I suspect that there would be much
resistance from a standards maintenance point of view,(I can already hear the
cries %&$§( !!! )

Maybe, it might be a good time to consider making TTCN-3 a
full blown OO testing language. I had not expected the language to begin taking
such a direction for a while yet, but,
if that is what the user community at large requires (is it
really?), then why not.

>>Adding multiple inheritence features will affect those who have
>>chosen to implement a TTCN-3 to language XXX which do not support OO.
>>
>>
>
>The inheritance can be unrolled at compile time and does not necessarily
>have to be captured by inheritance in the target language. We


Quite true, as C++ was usually transformed into some form of
mangled C! :-), then why not with TTCN-3!

are
>talking more or less about 'interface inheritance' and I think that it
>would make sense to allow multiple inheritance when we ensure that there
>are no name clashes between the parent component types.
>
>Of course, one could also devise a 'naming scheme' that would allow to
>deal with clashes upong multiple inheritance. I am just thinking out
>loud here:
>
>type component A {
> timer T := 1.0;
>}
>
>type component B {
> timer T := 10.0;
>}
>
>type component C : A,B {
> timer T := 100.0;
>}
>
>This could yield a component with 3 separate timers: A.T, B.T, and C.T.
>
>When used in a context of 'A', only A.T is known and is implicitly
>refered to by 'T':
>
>function f() runs on A {
> T.start;
> T.timeout; // after 1 second
>}
>
>When we are in the context of C, then we would get:
>
>function g() runs on C {
>
> T.start;
> T.timeout; // after 100 s
>
> B.T.start;
> B.T.timeout; // after 10 s
>
> A.T.start;
> A.T.timeout; // after 1 s
>}
>
>I am not entirely sure that this would be a good idea, though.

I tend to agree with you. I think the majority of testers wish to have a
'simple to use' notation, where test cases,
or test suites, can be understood using 'linear' thinking.
For many, concepts such as multiple inheritance requires
them to relearn (at least partially) how they design test cases. I don't know if
you see it this way,
since you are already 'biased' (likely not the right word, and not that it is a
bad thing either) towards OO design and development.


Probably
>that would make things too complicated. Opinions?
>
Complicated, maybe not, but confusing for sure! :-).

Cheers,

Claude.

>> [snip]
>>

>Stephan
>--
>
>Stephan Tobies Sr. Research Engineer, Nokia Research Center
>~ Mobile Networks Lab, Protocol Engineering Group
>E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Work Phone: +49-234-9842262
>Fax: +49-234-9843491
>Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>


--
Claude Desroches email:CDesroche@aol.com
Conformance Technologies Ltd. phone: +49 30 9606 7986
685 Cedar Point Road fax: +49 30 9606 7987
Penetanguishene Ontario, mobile 0174 701 6792
Canada

Hi Claude, hi all,

after considering Claude's input and some discussion with Thomas Deiss,
I will write the following CR:

* multiple inheritance without name clashes between component members
* ':' notation
* 'runs on compatibility checking' based on inheritance rather than
structural compatibility.

The last point is not crucial to the CR - it is more intended as an
option to the TTCN-3 maintainers, that would, in my point of view, make
this part of the language less complicated both from a conceptual and
tool vendors point of view, but trades this for backward compatibility.

Thanks for your input!

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi all,

couldn't we make then inheritance also applicable to other types - not
only component types, but also port types ... and what about data types?!

Cheers, Ina.

Stephan Tobies wrote:
> Hi Claude, hi all,
>
> after considering Claude's input and some discussion with Thomas Deiss,
> I will write the following CR:
>
> * multiple inheritance without name clashes between component members
> * ':' notation
> * 'runs on compatibility checking' based on inheritance rather than
> structural compatibility.
>
> The last point is not crucial to the CR - it is more intended as an
> option to the TTCN-3 maintainers, that would, in my point of view, make
> this part of the language less complicated both from a conceptual and
> tool vendors point of view, but trades this for backward compatibility.
>
> Thanks for your input!
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

ext Ina Schieferdecker wrote:

> Hi all,
>
> couldn't we make then inheritance also applicable to other types - not
> only component types, but also port types ... and what about data types?!
>

I think it is more diffecult with port types than it is with component
types. Code 'running on' a component type A will always be valid when
run on a component type B inheriting from A no matter what B adds to A.

Is the same true for port types? Not necessarily. Adding additional
types to a port may make certain map or connect statements illegal
because additional types mean additional constraints. Of course, this
might not really be a problem because the configuration statements refer
to a component port by name and not by (a possibly widened) reference.
This strange restriction of configuration statements that does not
allow, for example, to use port parameters, is what safes us here.

But I definitely see a problem when we talk about inheritance between
'normal' types - for example:

type record A {
integer x
};

type record B : A {
integer y
};

template B temp := { x := 1, y := 2 };

function f(in template A t, port P pt) {
pt.receive(t);
...
}

What happens now if we invoke f with template temp but receive a value
which is 'really' of type A? Should we get match, mismatch, or runtime
error? The problem here comes from the fact that a template is, in a
certain sense, something operational.

To sum up: I think it would work for ports, it is problematic for
arbitrary types.

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi Ina and everybody!

From a tool vendors perspective I reckon this could cause a whole bunch of problems initially but apart from that I think the language would gain in both respect (pardon my phrasing...;-)) and usefulness.

IMHO users are more likely to adopt a language with a straight forward approach than having to learn a language with lots of exceptions or addons.

I don't remember the initial reason for excluding inheritance from TTCN-3 but since most languages today allows for OO I think we quite safely can expect the users of TTCN-3 in the future (and now) possessing that skill...

Again this is what I think and I am used to people not thinking the same...;-)

BR

/Stefan

---

Original Message

---

From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: måndag den 24 november 2003 14:26
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Adding component type inheritance to the language


Hi all,

couldn't we make then inheritance also applicable to other types - not only component types, but also port types ... and what about data types?!

Cheers, Ina.

Stephan Tobies wrote:
> Hi Claude, hi all,
>
> after considering Claude's input and some discussion with Thomas
> Deiss, I will write the following CR:
>
> * multiple inheritance without name clashes between component members
> * ':' notation
> * 'runs on compatibility checking' based on inheritance rather than
> structural compatibility.
>
> The last point is not crucial to the CR - it is more intended as an
> option to the TTCN-3 maintainers, that would, in my point of view,
> make this part of the language less complicated both from a conceptual
> and tool vendors point of view, but trades this for backward
> compatibility.
>
> Thanks for your input!
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

Hi Stephan,

Stephan Tobies wrote:
> ext Ina Schieferdecker wrote:
>
>> Hi all,
>>
>> couldn't we make then inheritance also applicable to other types - not
>> only component types, but also port types ... and what about data types?!
>>
>
> I think it is more diffecult with port types than it is with component
> types. Code 'running on' a component type A will always be valid when
> run on a component type B inheriting from A no matter what B adds to A.
>
> Is the same true for port types? Not necessarily. Adding additional
> types to a port may make certain map or connect statements illegal
> because additional types mean additional constraints. Of course, this
> might not really be a problem because the configuration statements refer
> to a component port by name and not by (a possibly widened) reference.
> This strange restriction of configuration statements that does not
> allow, for example, to use port parameters, is what safes us here.

Currently, the compatibility for connect is defined for example as

outlist-PORT1 <= inlist-PORT2 and outlist-PORT2 <= inlist-PORT1 (with <=
meaning subset)

So, there is no problem to have e.g. a port type PORT from which PORT1
inherits adding an in-message type and from which PORT2 inherits adding
also an in-message - these can be connected. The subset rule can be
checked also in the case of inherited ports.

>
> But I definitely see a problem when we talk about inheritance between
> 'normal' types - for example:
>
> type record A {
> integer x
> };
>
> type record B : A {
> integer y
> };
>
> template B temp := { x := 1, y := 2 };
>
> function f(in template A t, port P pt) {
> pt.receive(t);
> ...
> }
>
> What happens now if we invoke f with template temp but receive a value
> which is 'really' of type A? Should we get match, mismatch, or runtime
> error? The problem here comes from the fact that a template is, in a
> certain sense, something operational.

Isn't that a question of definition: what do testers expect in such
cases ... I guess one would expect a match as I would see then the
refinement as an addon which is not being considered by the receive. But
maybe others see it differently?

Cheers, Ina.

>
> To sum up: I think it would work for ports, it is problematic for
> arbitrary types.
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---