HI Gyorgy,
The point of my comment was mostly targeted at the lack of consistency. Of
course, I understand why it was decided to do so, just that one of the
initial guidelines in defining TTCN-3 was to eliminate any type of implicit
behaviour and implicit semantics. Any exception in a language always makes
it more difficult for newcomers to learn the language properly, and also
runs the risk of increasing misconceptions, or misunderstanding with respect
to actual behaviour. :-)
Speaking from experience, most people wonÂ’t care too much about it, only
when results or behaviour deviate from the expected do most developers start
to investigate why things are working as they expect them too! :-)
Cheers,
Claude.
BluKaktus Communication phone: +49 (0)30 9606 7985
Edinburger Str. 39 fax: +49 (0)30 9606 7987
13349 Berlin mobile: +49 (0)174 701 6792
Germany email: This email address is being protected from spambots. You need JavaScript enabled to view it.
_____
From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of György Réthy
Sent: August 19, 2008 10:16 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: implicit meaning of omitting the inout keyword using timer as a
formal parameter
Hi Claude,
The default parameter kind 'in' is true for data (incl. component
references) parameters only. Yes, it is an additional rule that may be
difficult to remember (together with all other exceptions). But I don't
think that users need to remember this (or do care about it). It is natural
that when passing a timer (or port) as parameter, the same timer (port) is
seen inside the called function/altstep. It would be superflouos to require
writing inout for all timer parameters for consistency reasons.
BR, Gyorgy
_____
From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Claude Desroches
Sent: Tuesday, 19 August, 2008 12:09 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: implicit meaning of omitting the inout keyword using timer as a
formal parameter
Hi Everyone,
In section 5.4.1.3 Formal parameters of kind timer
As I understand, and remember, the general agreement with use of formal
parameters is that omitting the keyword in, out, or inout, implies the use
of the ‘in’ qualifier.
However, restriction a) indicates that by default timer is implicitly
qualified by inout.
This breaks the consistency of implicit assignment of the ‘in’ qualifier
for formal parameters. Adding such exceptions only makes things more
difficult for users new to TTCN-3 to learn, understand, and use correctly.
NOTE: Yes, it does make sense to use implicit inout qualification for
timers, but I just wanted to point out the obvious inconsistency. :-)
NOTE2: Developers should get into the habit of always adding the ‘in’,
‘out’ or ‘inout’ qualifier to ensure complete clarity of one’ intent.
Implicit semantics is for the most part dangerous, even if it does save a
few keystrokes. )-:
What do you think?
Cheers,
Claude.
BluKaktus Communication phone: +49 (0)30 9606 7985
Edinburger Str. 39 fax: +49 (0)30 9606 7987
13349 Berlin mobile: +49 (0)174 701 6792
Germany email: This email address is being protected from spambots. You need JavaScript enabled to view it.
