Stephan,
I feel that a good reason for keeping the timers in the altsteps
as they are would be preserving backwards compatibility with the
existing version of the standard. For tool vendors it would make
no difficulty to remove timers from altstep top-level declaration
list, however we should probably think of the existing user base
as well.
In my opinion, one of the major reasons of C++ language success
was that they have been very careful about preserving backwards
compatibility with previous versions of C++ and even C.
With TTCN-3, it was understandable that major changes have been
ongoing while the language has been maturing. Now, when the language
is in pretty good shape and it started receiving adoption, these
backwards-incompatible changes may bring more harm than benefit,
unless the reason for a change is truly compelling.
That said, personally I would vote in favour of all changes that let
the existing code run as it did before. Extending log statements is
a good example of change in that respect, as it simply adds new
functionality while preserving the existing one.
Reversing the order of evaluation of defaults, again, does not make any
difficulty for the tool vendor, however it may have subtle implications
for those users who have already written their TTCN-3 code keeping
currently published [FEB-2003] version of the TTCN-3 standard in their
minds. However, the reason for a change can be qualified as compelling
(more context-oriented default handling).
The timers you are referring to might be used inside nested branches
of an altstep body, for example in the following manner:
altstep A() runs on C
{
timer T;
[] p.receive
{
T.start(1.0);
T.timeout;
}
};
and there is no guarantee that not a single user has written this kind of
code already in his/her internal test suite. Besides, in my opinion the
reason for a change can hardly be qualified as compelling.
To sum up: why not being conservative?
Best regards,
Alexey Mednonogov
Software Engineer
OpenTTCN Oy
www.openttcn.com/
Stephan Tobies wrote:
> Hi,
>
> I think I have found a problem with local definitions in altsteps.
>
> Clause 16.2.2.0 allows the local definition of timers in altsteps, like
> this:
>
> altstep as() {
> timer t;
> [] some_alt {
> }
> };
>
> In my opinion, this should not be allowed because these timers can never
> be used:
>
> Clause 16.2.2.1 explicitly forbids to start timers during the
> initialization of the local definitions in the altstep - in our example
> above 't' may not be started.
>
> This means that all such timers can never have an influence on the
> selection of alternatives in the altstep. Of course, they may later be
> started in the body of an alternative of the altstep, but if the timer
> has its purpose in the body of that alternative, it might as well be
> declared in that body.
>
> Ok, this is not really a problem with the standard, but I would prefer
> to see timers eliminated from the allowed local definitions. If not
> somebody can come up with a good reason to have timers in this place, I
> am going to write a CR. So, speak up now of remain forever silent ;-).
>
> 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
> Mobile: +49-163-9842405
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
