Hi,

I don't think it worth to start this discussion as non-backward compatible changes are not possible in the language. There are too many test suites exist (both standard and "private") to invalidate them for the sake of ... (what?)

BR, Gyorgy

(BTW. I do not agree with most of these comments neither from the technical nor from the usability points of view)

>

---

Original Message

---

> 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 Martti
> Söderlund
> Sent: 2008. szeptember 26. 14:17
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Uniqueness of identifiers
>
> hi,
>
> I have a couple of notions about the descriptions used in the
> scoping rules. I'd like to state them with the reasoning that
> the more straightforward the specification, the lower the
> learning threshold, introduction to, and usage of TTCN-3 is.
> Also, I'd like to also help myself follow the discussion
> easier in the future...
>
> * The examples about using a field identifier as a type
> reference I think should not be valid, as the field name
> denotes a feature of the type, not a type (Resolving using
> the type of an expression is a different case). I would judge
> it like this because in general one might declare types
> within types, if the declaration rules allow it. When the
> declaration rules do not allow declaring types within types,
> there should be no reason to try to have a name lookup for
> types resolve a reference within a type definition to another
> field of the same type. When resolving type identifiers used
> in type definitions according to the visibility rules (trying
> to get to the scope of visibility of the identifier being
> resolved) the first scope attempted should be the scope of
> the type. Then if a particular field type must absolutely be
> used, it should be declared as a type.
>
> * The second is the example of overloading a type identifier
> with a field name. I don't think this is really usable, while
> it might be an interesting experiment, it does not in my
> opinion serve a purpose where overloading is commonly used.
> However, if describing types to be declaration scopes, one
> could say that the matching field expression hides the
> identifier of the field's type, which would be consistent
> with their usage in name lookup by visibility rules normally.
> If overloading is the alternative used, there should also be
> rules on the resolving of the overloading if the expressions
> of this type may contain both references to the field types
> and to the fields.
>
> * Thirdly, it should be accepted that in expressions,
> visibility rules include name lookup by the type of the
> expression is used (and allow overloading of identifiers more
> freely). Other than lexical scopes are already used, as I
> think function bodies already have component types as their
> scopes, why not allow types to be the scopes of expressions
> of the type. I think then it might be possible to remove the
> restrictions of the enumeration identifiers.
>
> * Lastly, I think it's the language user's choice to hide an
> identifier if they please (and I may contradict myself here).
> I think identifiers hiding other identifiers should not be
> restricted in a global scope, because that will only result
> in compilation problems when creating new programs. Any
> accidental matches will be reported by type resolving of expressions.
>
> I don't know if this is applicable to the current language
> specification, as backward compatibility should be preserved;
> Starting to use scopes as types might add a dimension to the
> visibility rules, but I'd still make the same arguments as I
> think the scoping rules should be easier to read.
>
> Best regards,
>
> Martti Söderlund, Specialist Software Engineer
>
> TietoEnator Telecom & Media
>
>
> ________________________________
>
> 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 Deiss,
> Thomas (NSN - DE/Duesseldorf)
> Sent: 26. syyskuuta 2008 14:15
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Uniqueness of identifiers
>
>
> Hello Gyorgy,
>
> In my opinion example 2 is not correct. The enumeration
> values are used also as field names within a record type, but
> clause 5.2.2 states "in the case of enumeration values the
> identifiers shall only be reused for enumeration values
> within other enumerated types" How does this fit together?
> What am I getting wrong?
>
> Best regards
>
> Thomas
>
>
>
> ________________________________
>
> 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 ext
> György Réthy
> Sent: Friday, 26. September 2008 12:55
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Uniqueness of identifiers
>
>
> Hi,
>
> This discussion starts to become a hard-to-follow to
> me, so I will try to sum up what is allowed acc. to the
> standard and what is not.
>
> 1) Field names of record and set types and names of
> alternatives in union types:
> shall be unique among the other field/alternative
> names of the given type only; i.e. may be the same as
> field/alternative/enumeration names in any other structured
> types and may be the same as the name of any global or local
> definition.
> i.e., allowed:
> type integer A;
> type integer B;
> type integer C;
> type record D {
> A A,
> B B,
> C C,
> D D optional, //optional is a must here
> because of the recursive reference
> C E
> }
> type record E {
> C C,
> D.E c
> // ^ pls. note, any dot reference shall start with the
> module or global definition name
> }
> type component CT {
> const integer c := 0
> }
>
> function F() {
> const integer c := 0;
> }
>
> and this is not allowed:
> type record E {
> integer C,
> octetstring C
> }
>
> 2) Enumeration names in enumerated types:
> Shall be unique within the type and may be identical as
> enumeration names in other enumerated types; but shall not
> clash with any other global or local names.
> i.e. allowed:
> type enumerated Enum1 { e1, e2, e3 }
> type enumerated Enum2 { e1, e2, e3 }
> type record R {
> Enum1 e1,
> Enum2 e2
> }
>
> and these are not allowed:
> type enumerated Enum3 { e11, e21, e31 }
> const integer e11 := 0;
> type integer e21;
> type component CT {
> var integer e31;
> }
> function F() {
> var Enum2 e21
> }
>
> 3) The rest:
> I suppose it should be rather clear, the scoping rules
> apply. Global names shall be unique and local names shall be
> different from global names, local names in a higher scope
> (i.e. local var name of a function with a runs on clause
> shall differ from the names in the comp. type definition)
> and other names in the same scope. Pls. note, there is no
> specific rules/exceptions e.g. for port instance names; ports
> in different component types are always in different scope
> units as component types are always global definitions. So,
> the sentence "The port names in a component type definition
> are local to that component type, i.e. another component type
> may have ports with the same names." is just drawing the
> attention to something that is the outcome of the scoping
> rules anyway.
> i.e. these are allowed:
> type component CT {
> const integer ci := 0;
> port PT P1;
> port PT P2
> }
> type component CTx {
> port PT P1
> }
>
> function F1() {
> const integer ci := 0;
> }
>
> function F2() {
> const integer ci := 0;
> }
>
> but these are not:
>

---

> type component CT1 {
> const integer ci := 0;
> }
>
> function F() runs on CT1 {
> const integer ci := 0;
> }
>

---

> type component CT2 {
> port PT P
> port PT P;
> }
>

---

> type integer I;
> function F() {
> var integer I
> }
>

---

> 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 Jacob Wieland
> Sent: 2008. szeptember 26. 11:03
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Uniqueness of identifiers
>
>
> Hello Thomas,
>
> Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
>
> Hello Jacob,
>
> let me just restrict for the moment to
> the example with the type reference. Please find my comment below.
>
> Same here ;-)
>
>
>
>
>
> <--- snip, TD --->
>
> The possibility to
> refer to the type of a record field creates an interesting
> puzzle. What's the type of the field V.d: boolean or integer?
> type record U { integer T };
> type record V {
> record {boolean T} U,
> U.T d
> }
>
> I think V.d must be integer,
> because you cannot refer to other fields in the type of the
> declaration of a field (because of the rule that these
> names need not be disjoint and
> therefore could never be disambiguated via a prefix), but
> only to globally declared types.
> Thus, U.T must mean field T of
> type U, which is integer.
>
>
> Note that U in the field definition
> 'record {boolean T} U' is not the name of a type, which does
> not have to be unique as you correctly observe. U is the name
> of a field, and this has to be unique within V.
>
> I have noted. U is both the name of a type and
> the name of a record field. Since it is not possible to
> reference the record field without using the type prefix (V.U
> in your example), the reference 'U' in 'U.T d' must mean the
> type U, not the field U.
>
>
> Why should it not be possible to refer
> to types of fields of the same record?
>
>
> Of course it is possible, but not without the
> explicit type prefix, as field names can only be referenced
> relative to something.
>
>
> type record X {
> record of boolean b;
> X.b c
> }
>
> should be ok, isn't it?
>
> Yes, here you correctly reference the field b
> by using the type prefix X.
>
> BR, Jacob
>
>
> --
>
>

---

>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34
> Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20
> Internet www.testingtech.com
>
>

---

>

---

>
> <--- snip, TD --->
>
>
>
> --
>
>

---

>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet
> www.testingtech.com
>
>

---

>

---

>
> UPCOMING EVENTS!
>
> September 24-26, Conquest, Booth #004
> Potsdam, Germany
> www.isqi.org/konferenzen/conquest/2008/
>
> September 27, ASQF Golf Cup
> Potsdam, Germany
> www.asqf.de/veranstaltungen/4-asqf-golf-cup/
>
> October 15, Free Webinar "TTCN-3 for Test Automation"
> www.testingtech.com/services/ttcn3_webinar.php
>
>
>

---

>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles,
> Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and
> privileged material for the
> sole use of the intended recipient. Any review,
> use, distribution or
> disclosure by others is strictly prohibited. If
> you are not the intended
> recipient (or authorized to receive for the
> recipient), please contact
> the sender by reply e-mail and delete all
> copies of this message.
>
>

Hi Roland,


Ooopppsss...

Thanks for catching the error; I reversed the type and field. :-)

Claude.


BluKaktus Communications 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.

>

---

Original Message

---

> 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 Roland Gecse
> Sent: September 26, 2008 6:53 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Uniqueness of identifiers
>
> Hi Claude,
>
> I believe you mistyped -- your 2nd sample is legal, too!
>
> Roland.
>
> > type record sample_record_type { // this type is illegal.
> > A A,
> > B B,
> > C C,
> > C D
> > }

Thanks. Reversed the fields as Roland indicatedÂ…



Cheers,



Claude.





BluKaktus Communications 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: September 26, 2008 8:37 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers



Hi Claude,



Your analysis, unfortunately, is incorrect.

"

type record sample_record_type { // this type is illegal.
A A,
B B,
C C,
C D // TTCN-3 requires uniqueness of
identifiers within the same

"

is perfectly legal. the standard says in $6.2.1: "The element identifiers
are local to the record and shall be unique within the record (but do not
have to be globally unique). " The element identifiers are A,B,C and D, they
are unique. Dont mix element identifiers by the type of the elements. In all
references (value notations, template definitions, just referring a field
etc.) only the element identifiers are used, never their type.


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: 2008. szeptember 25. 20:20
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers

Hi Everyone,



CorinnaÂ’s and JacobÂ’s analysis are correct.




type record sample_record_type { // this type is completely legal.
A A,
B B,
C C

}



type record sample_record_type { // this type is illegal.
A A,
B B,
C C,
C D // TTCN-3 requires uniqueness of
identifiers within the same
// scope branch as well as within a given
record or set.
// If this were legal, there would need to
be a way to determine
// which C is being referenced. In the
case of template definition
// field ordering can be used to determine
this, but in an assignment
// this would only be possible by tagging
the field with its type.

// It just easier to avoid such things to
start with.

}





Whichever the case, I would not recommend defining records where the field
name and the field type is the same. Even if it is allowed, its simply
asking for trouble. Why would someone want to create such needless
confusion???



Just my two cents for this evening. :-)









Claude.



BluKaktus Communications 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 Jacob Wieland
Sent: September 25, 2008 5:32 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers



Hello Thomas,

I disagree, I think the example is totally valid.

Record 'scopes' are not scope units as statement blocks or the module body.
There is no conflict as these names can only be used
on the left hand side of a field assignment or on the right hand side of a
dot. Thus, they can never be confused with names declared
in the same scope. The only restriction is that inside the same record/set
'scope', the field names must be unique to avoid
nameclashes between them.

I also think that that is what the standard describes when referencing the
exception of field names which Elena quoted.

If your reasoning were true, then it should also not be possible to
introduce a record with a field f which is itself again
a record with field f. But, since the first field f could also have a record
type with a field f which was declared in a different module,
this would have to be disallowed as well (even though in both cases there is
no name conflict anywhere), but isn't.

Thus, either your reasoning is flawed or the standard is inconsistent. In
this instant, I vote the former ;-)

Best regards,

Jacob Wieland

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Elena and Corinna,

It's my understanding that Corinna's example is invalid. The same identifier
has been used twice in the same scope unit (the module), once as identifier
of a type and once as identifier of a field.

Regarding uniqueness of fieldnames of different record types and of
enumeration values.

type record R1 { integer a, boolean b};
type record R2 { integer a, boolean b};
type enumerated E1 {c};

would be ok. What's not ok is to define in addition:

type enumerated E2 { b, c };

The identifier b can be used only as an enumeration value. But it is also
used as fieldname of a record. The definition of the enumeration value c in
both enumerations E1 and E2 is fine.

That's my understanding of clause 5.2.2.

Hope this helps ... stimulates discussion to clarify this issue. Seems that
the standards leaves room for interpretation.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|

---

Original Message

---

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 ext
Elena de Vega
Sent: Thursday, 25. September 2008 16:15
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers

Hi Corinna,

Your example is possible because you can have a subtype field
with the same name that its type. The type and the field have
different scope then there is no problem.

type record sample_record_type {
A A,
B B,
C C
}



The enumerated types:

There isn't the same restriction for structured types; it's
only for enumerated types.
You can see enumerated examples on the page 41 (core v3.4.1).


Elena de Vega Gil


TEL: (+34) 91 353 15 64

FAX: (+34) 91 359 61 79

E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.







Metodos Y Tecnología (MTP)

Paseo de la Castellana 182, 10

28046 Madrid, España

---

Mensaje original

---

De: 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.] En nombre de Corinna Wiegert
Enviado el: jueves, 25 de septiembre de 2008 14:05
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Uniqueness of identifiers

Dear all,

is the following type definition allowed if A, B and C are
already used as identifiers for other types?

type record sample_record_type {
A A,
B B,
C C
}

This is possible because you can have a subtype field with the
same name that its type. The type and the field have different
scope then there are not problem.

The core spec (3.4.1) says in 5.2.2:

"TTCN-3 requires uniqueness of identifiers, i.e. all
identifiers in the same scope hierarchy shall be distinctive.
This means that a declaration in a lower level of scope shall
not re-use the same identifier as a declaration in a higher
level of scope in the same branch of the scope hierarchy.
Identifiers for fields of structured types, enumeration values
and groups do not have to be globally unique, however in the
case of enumeration values the identifiers shall only be
reused for enumeration values within other enumerated types."

In my understanding the identifiers of enumeration values may
only be reused for other enumeration values. Does a similar
restriction apply for fields of structured types or is it
allowed to reuse the identifiers of fields of structured types
e. g. for other type names? Are there any details or examples
in the spec on this?

Thanks in advance and regards,

Corinna

---

---

Corinna Wiegert
Rohde & Schwarz GmbH & Co. KG
Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
81614 München / GERMANY

Tel: +49-89-4129-13498
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Web: www.rohde-schwarz.com

---

---

=










--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.