|
Welcome,
Guest
|
|
TOPIC: Uniqueness of identifiers
Uniqueness of identifiers 25 Sep 2008 12:05 #7439
|
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 } 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 |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 25 Sep 2008 14:15 #7440
|
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 = |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 25 Sep 2008 15:14 #7441
|
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 > > = > |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 25 Sep 2008 15:31 #7442
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 25 Sep 2008 15:39 #7443
|
Hi,
When you define a record, this has its own scope, so you can repeat identifiers form higher, levels and reference the new fields with the name of the record as a path. Fields in a record are not global, so there is no problem of collision related to the identifiers. That is the reason why in my opinion the example of the record given by Corinna is correct.  Iván Navarro Azurmendi   Pº de la Castellana, 182 - 10ª planta 28046 - Madrid Tel.: +34 913531564 Fax: +34 913596179 www.mtp.es 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 Deiss, Thomas (NSN - DE/Duesseldorf) Enviado el: jueves, 25 de septiembre de 2008 16:15 Para: This email address is being protected from spambots. You need JavaScript enabled to view it. Asunto: Re: Uniqueness of identifiers 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 > > = > |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 25 Sep 2008 18:20 #7444
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 04:52 #7446
|
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 > } |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 06:37 #7447
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 08:07 #7448
|
Hello Jacob and others,
I'm not yet convinced by the arguments provided so far. Please find my arguments below. And sure, I would also prefer that my arguments are flawed instead of the standard being inconsistent :-) Please consider the following more as an analysis of what the standard defines. I would not object to clarify the standard such that the understanding of Jacob, Ivan, Elena, and other is clearly expressed within the standard. 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 Jacob Wieland Sent: Thursday, 25. September 2008 17:32 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. I agree, record type definitions are not scope units. From the seven scope units listed in clause 5.2, two are relevant regarding this issue: module definitions part and component types. Note that it is only component types that are a scope unit, but not other type definitions. Clause 5.2.2 presents the requirements on uniqueness of identifiers. "TTCN‑3 requires uniqueness of identifiers, i.e. all identifiers in the same scope hierarchy shall be distinctive. " So, clearly the following is incorrect (two type definitions with the same name). type record R {integer a}; type record R {integer b}; I think we all agree on this. Then we have "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." For a component type definition, which is a new scope unit itself, this means that the element names in the component type cannot reuse identifiers from the module. type record S {integer a}; const integer c := 1; type component CT { var boolean S; var integer c } For the element named S, an identifier of the higher scope unit is reused. And the same holds for the element named c. Note that it does not make a difference whether the reused identifier is from a type or some other definition. Clause 6.2.10.1 only states that port names are local to the component type. Timers, variables, and constants are not mentioned. Therefore, I do not see that the standard allows exceptions to not allowing reuse of identifiers on module level. Note also that the elements of a component type are accessed without using the dot notation. Note also that this rule disallows the use of identifiers on module level as names of local variables, constants, etc. within functions, etc. Now the critical statement: "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" And let me add the corresponding sentence from clause 6.2.1 (thanks Gyorgy!), a similar statement exists for set types. "The element identifiers are local to the record and shall be unique within the record (but do not have to be globally unique). " the corresponding from clause 6.2.4 for enumerations. "Enumeration identifiers shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible within the context of the given type only. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy " and also the corresponding sentence from clause 6.2.10.1 "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. Port names in the same component type definition shall all have unique names." There is no corresponding exception for union types in clause 6.2.5. Actually I think the different alternatives in unions should just be handled as the field names of records. This problem boils down to how 'globally unique' shall be understood. It is stated that field names do not have to be globally unique. For me it is not clear that this allows to reuse the name of global definitions, the uniqueness of the identifier used on the module level has not been relaxed. I simply don't see this. 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. 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 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. Good point. Obviously this has to be allowed. Without nested type definitions this is not a problem. But also in the case of nested type definitions this has to be allowed. 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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 08:25 #7449
|
I'm pretty sure that Claude confused the order type/fieldname with the
order in ASN.1 and meant: field-names A, B, C, D, with types A, B, C, C, respectively. Then, his argument would make sense, otherwise, I have to agree With György ;-) BR, Jacob György Réthy wrote: > 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. J > > > > > > > > > > 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. <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. <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. <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. <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. <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. <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 <www.testingtech.com> > > > > > > UPCOMING EVENTS! > > > > September 24-26, Conquest, Booth #004 > > Potsdam, Germany > > www.isqi.org/konferenzen/conquest/2008/ <www.isqi.org/konferenzen/conquest/2008/> > > > > September 27, ASQF Golf Cup > > Potsdam, Germany > > www.asqf.de/veranstaltungen/4-asqf-golf-cup/ <www.asqf.de/veranstaltungen/4-asqf-golf-cup/> > > > > October 15, Free Webinar "TTCN-3 for Test Automation" > > www.testingtech.com/services/ttcn3_webinar.php <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. > -- 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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 08:40 #7450
|
Hello Thomas,
Deiss, Thomas (NSN - DE/Duesseldorf) wrote: > Hello Jacob and others, > > I'm not yet convinced by the arguments provided so far. > Please find my arguments below. And sure, I would also prefer that my > arguments are flawed instead of the standard being inconsistent :-) > > Please consider the following more as an analysis of what the standard > defines. I would not object to clarify the standard such that the > understanding of Jacob, Ivan, Elena, and other is clearly expressed > within the standard. > I think it already is stated (with the exception of unions that you found) clearly enough already, but more clarity, as long as our understanding does not change will probably not hurt. See my other comments inline. > > > Record 'scopes' are not scope units as statement blocks or the > module body. > > > I agree, record type definitions are not scope units. From the seven > scope units listed in clause 5.2, two are relevant regarding this > issue: module definitions part and component types. Note that it is > only component types that are a scope unit, but not other type > definitions. > > Clause 5.2.2 presents the requirements on uniqueness of identifiers. > > "TTCN‑3 requires uniqueness of identifiers, i.e. all identifiers in > the same scope hierarchy shall be distinctive. " > So, clearly the following is incorrect (two type definitions with the > same name). > type record R {integer a}; > type record R {integer b}; > I think we all agree on this. I agree. > > Then we have > "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." > For a component type definition, which is a new scope unit itself, > this means that the element names in the component type cannot reuse > identifiers from the module. > type record S {integer a}; > const integer c := 1; > type component CT { > var boolean S; > var integer c > } > For the element named S, an identifier of the higher scope unit is > reused. And the same holds for the element named c. > Note that it does not make a difference whether the reused > identifier is from a type or some other definition. > Clause 6.2.10.1 only states that port names are local to the component > type. Timers, variables, and constants are not mentioned. Therefore, I > do not see that the standard allows exceptions to not allowing reuse > of identifiers on module level. > Note also that the elements of a component type are accessed without > using the dot notation. > Note also that this rule disallows the use of identifiers on module > level as names of local variables, constants, etc. within functions, etc. > > Now the critical statement: > "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" > And let me add the corresponding sentence from clause 6.2.1 (thanks > Gyorgy!), a similar statement exists for set types. > "The element identifiers are local to the *record* and shall be unique > within the *record* (but do not have to be globally unique). " > the corresponding from clause 6.2.4 for enumerations. > "Enumeration identifiers shall be unique within the enumerated type > (but do not have to be globally unique) and are consequently visible > within the context of the given type only. Enumeration identifiers > shall only be reused within other structured type definitions and > shall not be used for identifiers of local or global visibility at the > same or a lower level of the same branch of the scope hierarchy " > and also the corresponding sentence from clause 6.2.10.1 > "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. Port names in the same component type definition shall all > have unique names." > There is no corresponding exception for union types in clause 6.2.5. > Actually I think the different alternatives in unions should just be > handled as the field names of records. I agree. > > This problem boils down to how 'globally unique' shall be understood. > It is stated that field names do not have to be globally unique. For > me it is not clear that this allows to reuse the name of global > definitions, the uniqueness of the identifier used on the module level > has not been relaxed. I simply don't see this. I think the reason is this: since record 'scopes' are not actually scopes and thus not part of any 'scope hierarchy', their field identifiers do not clash with names in the scope hierarchy and there is no relaxation of the property that names in the scope hierarchy have to be globally unique. > > 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. > > > 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. Best regards, 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 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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 08:51 #7451
|
Hello Jacob,
let me just restrict for the moment to the example with the type reference. Please find my comment below. best regards Thomas | Thomas Deiß | | Nokia Siemens Networks | | Heltorferstrasse 21 | | D-40472 Düsseldorf | | Mobile: +49 1639842217 | | internal: 827 2217 | | email: This email address is being protected from spambots. You need JavaScript enabled to view it. | <--- 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. Why should it not be possible to refer to types of fields of the same record? type record X { record of boolean b; X.b c } should be ok, isn't it? Best regards, 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 ---> |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 09:02 #7452
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 10:55 #7453
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 11:14 #7454
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 11:52 #7455
|
Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
> 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? > I think what is MEANT here is that they shall not be used as 'scoped names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations. Maybe this should be clarified. BR, Jacob > 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. > > -- 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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 12:16 #7456
|
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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 12:24 #7457
|
Hi Thomas and others,
The text precisely is: " Enumeration identifiers shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible within the context of the given type only. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)." So, it does not say that can be re-used in other enumarated types but says that can be re-used in other structured types. Jacob's comment is correct. When discussing enumeration names many years ago, the majority opinion was to exclude potential name clashes between enumerations and names of other *definitions*, let it be local or global. 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. 13:53 To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: Uniqueness of identifiers Deiss, Thomas (NSN - DE/Duesseldorf) wrote: 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? I think what is MEANT here is that they shall not be used as 'scoped names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations. Maybe this should be clarified. BR, Jacob 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. -- 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. |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 13:14 #7458
|
--- On Fri, 26/9/08, György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
From: György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> Subject: Re: Uniqueness of identifiers To: This email address is being protected from spambots. You need JavaScript enabled to view it. Date: Friday, 26 September, 2008, 5:54 PM Hi Thomas and others,  The text precisely is: " Enumeration identifiers shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible within the context of the given type only. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)." So, it does not say that can be re-used in other enumarated types but says that can be re-used in other structured types.  Jacob's comment is correct. When discussing enumeration names many years ago, the majority opinion was to exclude potential name clashes between enumerations and names of other *definitions*, let it be local or global.  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. 13:53 To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: Uniqueness of identifiers Deiss, Thomas (NSN - DE/Duesseldorf) wrote: 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? I think what is MEANT here is that they shall not be used as 'scoped names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations. Maybe this should be clarified. BR, Jacob 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. -- 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. Unlimited freedom, unlimited storage. Get it now, on help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ |
|
The administrator has disabled public write access.
|
Uniqueness of identifiers 26 Sep 2008 13:36 #7459
|
Hello Gyorgy,
it seems to me that the clauses in 6.2.4 and 5.2.2 are contradictory. The 6.2.x clauses seem to be more precise. Should we have a CR to remove the description of the exceptional cases from 5.2.2 and instead point to the corresponding clauses of 6.2.x? 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 14:25 To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: Uniqueness of identifiers Hi Thomas and others, The text precisely is: " Enumeration identifiers shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible within the context of the given type only. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)." So, it does not say that can be re-used in other enumarated types but says that can be re-used in other structured types. Jacob's comment is correct. When discussing enumeration names many years ago, the majority opinion was to exclude potential name clashes between enumerations and names of other *definitions*, let it be local or global. 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. 13:53 To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: Uniqueness of identifiers Deiss, Thomas (NSN - DE/Duesseldorf) wrote: 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? I think what is MEANT here is that they shall not be used as 'scoped names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations. Maybe this should be clarified. BR, Jacob 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. -- 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. |
|
The administrator has disabled public write access.
|
|
