Hi all,
this is indeed an open issue for which also the quite opposite view exist: arrays belong to the type system in TTCN-3. Semantically, arrays and record of are the same.
As the array syntax is in many cases convenient and has always been in the standard we should keep it.
With best regards,
Ina.
________________________________
From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of György Réthy
Sent: Wednesday, September 26, 2007 9:36 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Arraydef in type definitions
Hi,
This is an old unsolved issue. We have a syntactical element without any meaning. One can suppose what it means but it is not specified. Ericsson's view for many years now that [ArrayDef] simply shall be deleted from the rule as subtyping can/shall be solved using [SubTypeSpec].
I know there is at least one tool supporting [ArrayDef] but in fact no one forbids to support it further on for backward compatibility (and probably give a warning on its use). We also have such "old burden"-s like value returning done.
In summary Ericsson would like to add [ArrayDef] in rule 48 to the deprecated language features.
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 Thomas Deiss
Sent: Tuesday, 25 September, 2007 2:35 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Arraydef in type definitions
Hello together,
Please have a look at rule 48 of the BNF (edition 3.2.1)
48. SubTypeDef ::= Type (SubTypeIdentifier | AddressKeyword) [ArrayDef] [SubTypeSpec]
I was asked to explain what the 'ArrayDef' is used for. But actually I have been unable to do so. What I have found in clause 6.2.7 is that arrays are not types. When defining a variable actually an array can be defined. But this can be done by other rules (287 - 289).
So, does the rule above mean that one can actual write a type definition such as
type charstring MyCS [4..8] length(15);
despite the explanation that arrays are not types? To me this would be a contradiction.
Can anyone share some insight on this topic? For which kind of definitions should this ArrayDef be used? Thanks.
Best regards
Thomas
| Thomas Deiß |
| Nokia Networks GmbH |
| Meesmannstraße 103 |
| D-44807 Bochum |
| Mobile: +49 1639842217 |
| Direct: +49 2349842217 |
| Fax: +49 2349843491 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |
Nokia Networks GmbH
Sitz der Gesellschaft: Bochum
Amtsgericht Bochum: HRB 11180
Ust-Id.-Nr./ VAT ID: DE814765854
WEEE-Reg.-Nr. DE 51797011
Geschäftsführer: Dr. Ulrich Halka
Nokia Networks GmbH arbeitet auf Rechnung der Nokia Siemens Networks
Nokia Networks GmbH operates for the account of Nokia Siemens Networks
Important Note: This e-mail and any attachment are confidential and may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachment or disclose the contents to any other person. Thank you for your cooperation.
Wichtiger Hinweis: Dieses E-Mail und etwaige Anlagen können Betriebs- oder Geschäftsgeheimnisse, dem Anwaltsgeheimnis unterliegende oder sonstige vertrauliche Informationen enthalten. Sollten Sie dieses E-Mail irrtümlich erhalten haben, ist Ihnen der Status dieses E-Mails bekannt. Bitte benachrichtigen Sie uns in diesem Fall sofort durch Antwort-Mail und löschen Sie dieses E-Mail nebst etwaigen Anlagen von Ihrem System. Ebenso dürfen Sie dieses E-Mail oder seine Anlagen nicht kopieren oder an Dritte weitergeben. Vielen Dank.
