Welcome,
Guest
|
|
TOPIC: Adding component type inheritance to the language
Adding component type inheritance to the language 21 Nov 2003 11:42 #6564
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 21 Nov 2003 14:55 #6579
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 10:00 #6589
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 12:32 #6591
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 13:13 #6592
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 13:25 #6593
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 14:07 #6594
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 14:18 #6595
|
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 |
The administrator has disabled public write access.
|
Adding component type inheritance to the language 24 Nov 2003 17:34 #6596
|
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 |
The administrator has disabled public write access.
|
|