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
