0006722: Visibility is not taken into account in component compatibility

(0012038)
Jacob Wieland - Spirent (reporter)
15-04-2014 13:55

Could you elaborate on what the problem is? Visibility normally is only interesting on the context-checking level. How does that influence component compatibility rules?

(0012237)
Gyorgy Rethy (reporter)
06-10-2014 16:11

Take the straighforward approach: visibility has to be the same in the parent and in the child.

(0012248)
Axel Rennoch (developer)
07-10-2014 10:19

additional rule added to consider visibility for compatibility

(0012301)
Jacob Wieland - Spirent (reporter)
08-10-2014 16:34

Sorry, can you please explain what visibility has to do with compatibility. Visibility normally only affects which names I can reference/use. So,if a name is not visible from my point of reference, I cannot use it. What has that to do with component type compatibility.

If a function is defined on a component type which is not visible to me but I know a compatible component type - why should I not be allowed to run the function on that component type?

(0012311)
Gyorgy Rethy (reporter)
09-10-2014 10:22

STF discussion: componenet type need not be visible at places where a function with a compatible component type in its run on clause is called. Check this and make explicit if not defined yet is clause 8.2.3.1.

(0012346)
Axel Rennoch (developer)
10-10-2014 10:28

In 8.2.3.1 restriction d) appears to be sufficient. In addition we have example 5 which addresses such component extension.

From this view there is no need for any more change and the CR may be closed.

(0012347)
Axel Rennoch (developer)
10-10-2014 10:30

CR do not need any changes and can be closed.

(0012395)
Jens Grabowski (manager)
04-11-2014 12:40

8.2.3.1 restriction d)
"A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5)."

And example 5:

EXAMPLE 5: Importing local definitions transitively
    module A {
      type enumerated MyEnum_Type { enumX, enumY, enumZ}
      type record MyRec { integer a, integer b }
      type component MyComp { var MyRec v_Rec := { a := 5 } }
    }

    module B {
      import from A all;
      modulepar MyEnum_Type px_MyModulePar := enumY;
      type component MyCompUser extends MyComp {}
    }

    module C {
      import from B all;
      testcase TC() runs on MyCompUser {
        if (px_MyModulePar == enumY) {
          // the enumerated value enumY is know in C without explicitly
              // importing it from A
          setverdict(pass)
        }
        if (v_Rec.a == 5) {
          v_Rec.b := v_Rec.a;
          // Both the variable name v_Rec and the record field names are
              //known in C without
          // explicitly importing them from A
          setverdict (pass)
        }
      }
    }

should do the job. Thus, no changes need to be implemented in the standard.

(0012619)
Gyorgy Rethy (reporter)
05-01-2015 16:13

No change is needed in the stanadrd.

Issue History
Date Modified	Username	Field	Change
10-04-2014 11:52	Gyorgy Rethy	New Issue
15-04-2014 13:55	Jacob Wieland - Spirent	Note Added: 0012038
18-06-2014 08:40	Gyorgy Rethy	Target Version	=> v4.7.1 (published 2015-06)
18-06-2014 08:40	Gyorgy Rethy	Description Updated	View Revisions
06-10-2014 16:11	Gyorgy Rethy	Note Added: 0012237
06-10-2014 16:11	Gyorgy Rethy	Assigned To	=> Axel Rennoch
06-10-2014 16:11	Gyorgy Rethy	Status	new => assigned
07-10-2014 10:19	Axel Rennoch	File Added: draft-res-6722.docx
07-10-2014 10:19	Axel Rennoch	Note Added: 0012248
07-10-2014 10:20	Axel Rennoch	Assigned To	Axel Rennoch => Gyorgy Rethy
07-10-2014 10:20	Axel Rennoch	Status	assigned => confirmed
08-10-2014 09:30	Gyorgy Rethy	Assigned To	Gyorgy Rethy => Jens Grabowski
08-10-2014 14:23	Jens Grabowski	Status	confirmed => resolved
08-10-2014 14:23	Jens Grabowski	Resolution	open => fixed
08-10-2014 14:23	Jens Grabowski	Assigned To	Jens Grabowski => Gyorgy Rethy
08-10-2014 16:34	Jacob Wieland - Spirent	Note Added: 0012301
08-10-2014 16:34	Jacob Wieland - Spirent	Status	resolved => feedback
08-10-2014 16:34	Jacob Wieland - Spirent	Resolution	fixed => reopened
09-10-2014 10:22	Gyorgy Rethy	Note Added: 0012311
09-10-2014 10:22	Gyorgy Rethy	Status	feedback => assigned
10-10-2014 10:28	Axel Rennoch	Note Added: 0012346
10-10-2014 10:30	Axel Rennoch	Note Added: 0012347
10-10-2014 10:30	Axel Rennoch	Status	assigned => confirmed
03-11-2014 16:51	Gyorgy Rethy	Assigned To	Gyorgy Rethy => Jens Grabowski
04-11-2014 12:40	Jens Grabowski	Note Added: 0012395
04-11-2014 12:41	Jens Grabowski	Status	confirmed => resolved
04-11-2014 12:41	Jens Grabowski	Resolution	reopened => fixed
04-11-2014 12:41	Jens Grabowski	Assigned To	Jens Grabowski => Gyorgy Rethy
05-01-2015 16:13	Gyorgy Rethy	Note Added: 0012619
05-01-2015 16:13	Gyorgy Rethy	Status	resolved => closed
05-01-2015 16:13	Gyorgy Rethy	Fixed in Version	=> v4.7.1 (published 2015-06)

Notes
(0012038) Jacob Wieland - Spirent (reporter) 15-04-2014 13:55	Could you elaborate on what the problem is? Visibility normally is only interesting on the context-checking level. How does that influence component compatibility rules?

(0012237) Gyorgy Rethy (reporter) 06-10-2014 16:11	Take the straighforward approach: visibility has to be the same in the parent and in the child.

(0012248) Axel Rennoch (developer) 07-10-2014 10:19	additional rule added to consider visibility for compatibility

(0012301) Jacob Wieland - Spirent (reporter) 08-10-2014 16:34	Sorry, can you please explain what visibility has to do with compatibility. Visibility normally only affects which names I can reference/use. So,if a name is not visible from my point of reference, I cannot use it. What has that to do with component type compatibility. If a function is defined on a component type which is not visible to me but I know a compatible component type - why should I not be allowed to run the function on that component type?

(0012311) Gyorgy Rethy (reporter) 09-10-2014 10:22	STF discussion: componenet type need not be visible at places where a function with a compatible component type in its run on clause is called. Check this and make explicit if not defined yet is clause 8.2.3.1.

(0012346) Axel Rennoch (developer) 10-10-2014 10:28	In 8.2.3.1 restriction d) appears to be sufficient. In addition we have example 5 which addresses such component extension. From this view there is no need for any more change and the CR may be closed.

(0012347) Axel Rennoch (developer) 10-10-2014 10:30	CR do not need any changes and can be closed.

(0012395) Jens Grabowski (manager) 04-11-2014 12:40	8.2.3.1 restriction d) "A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5)." And example 5: EXAMPLE 5: Importing local definitions transitively module A { type enumerated MyEnum_Type { enumX, enumY, enumZ} type record MyRec { integer a, integer b } type component MyComp { var MyRec v_Rec := { a := 5 } } } module B { import from A all; modulepar MyEnum_Type px_MyModulePar := enumY; type component MyCompUser extends MyComp {} } module C { import from B all; testcase TC() runs on MyCompUser { if (px_MyModulePar == enumY) { // the enumerated value enumY is know in C without explicitly // importing it from A setverdict(pass) } if (v_Rec.a == 5) { v_Rec.b := v_Rec.a; // Both the variable name v_Rec and the record field names are //known in C without // explicitly importing them from A setverdict (pass) } } } should do the job. Thus, no changes need to be implemented in the standard.

(0012619) Gyorgy Rethy (reporter) 05-01-2015 16:13	No change is needed in the stanadrd.

Relationships

ETSI's Bug Tracker