Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003382Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 10:0718-07-2008 10:54
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Summary0003382: cyclic import
DescriptionClause 8.2.3 states that cyclic imports are forbidden.
It is unclear whether the example below qualifies as cyclic import.

module a {
  import from b { type x }
  type record of x list_x;
}

module b {
  type integer x;
  import from a { type list_x }
}


I suggest to add a sentence to 8.2.3 that the cycles are considered on module level:
"Cyclic imports are forbidden. Cycles are determined on module level"
TagsNo tags attached.
Clause Reference(s)8.2.3
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Attached Files

- Relationships

-  Notes
(0006285)
Jens Grabowski (manager)
15-07-2008 16:20

 Proposal for resolution:

Delete restriction "h) Cyclic imports are forbidden" in Clause 8.2.3.1.

Reasons:
- The original reason for introducing this restriction was to avoid cyclic definitions. However, the problem of cyclic definitions has to be solved on module level. See CR 3379

- Furthermore, originally the cyclic imports restriction was meant to work on definition level but could be misinterpreted as a restriction on module level. For example:
module A imports const B-const of type integer from Module B
module B imports const A-const of type integer from Module A
can be interpretet as a cyclic import on module level (module A imports from B and B imports from A), but causes no problems at all.
(0006319)
Thomas Deiß (reporter)
18-07-2008 08:44

 Proposed solution (see previous note) is ok.

- Issue History
Date Modified Username Field Change
16-05-2008 10:07 Thomas Deiß New Issue
16-05-2008 10:07 Thomas Deiß Status new => assigned
16-05-2008 10:07 Thomas Deiß Assigned To => Ina Schieferdecker
16-05-2008 10:07 Thomas Deiß Clause Reference(s) => 8.2.3
16-05-2008 10:07 Thomas Deiß Source (company - Author) => Nokia Siemens Networks, Thomas Deiß
14-07-2008 15:23 Ina Schieferdecker Assigned To Ina Schieferdecker => Jens Grabowski
15-07-2008 16:20 Jens Grabowski Note Added: 0006285
16-07-2008 09:37 Jens Grabowski Assigned To Jens Grabowski => Thomas Deiß
18-07-2008 08:44 Thomas Deiß Note Added: 0006319
18-07-2008 08:44 Thomas Deiß Assigned To Thomas Deiß => Ina Schieferdecker
18-07-2008 08:44 Thomas Deiß Resolution open => fixed
18-07-2008 10:41 Ina Schieferdecker Status assigned => closed
18-07-2008 10:41 Ina Schieferdecker Fixed in Version => Edition 4.1.1 (not yet published)
18-07-2008 10:41 Ina Schieferdecker Target Version => Edition 4.1.1 (not yet published)
18-07-2008 10:54 Ina Schieferdecker File Added: CR-3379-Resolution-JG-TD-IS-080719.doc
18-07-2008 10:55 Ina Schieferdecker File Deleted: CR-3379-Resolution-JG-TD-IS-080719.doc

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker