Issue 1305: Illegal IDL redefinitions (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: * Package Template attribute "enclosing_package_ref", if packages are nested. (Section 7.3.1, page 7-8) * Type Template attribute "enclosing_package_ref", for any subtype. (Section 7.3.4, page 7-12). Resolution: resolved, close issue Revised Text: Actions taken: May 4, 1998: received issue May 8, 2000: closed issue Discussion: Discussion: After careful thought, we have concluded that there is no acceptable way to name-mangle the "enclosing_package_ref" attributes to avoid this problem. Furthermore, the proposal for Package clustering / consolidations ( Issue 2176) means that a "top-level" Package instance can now be inside the extent of another Package instance. This cannot be expressed statically in the IDL. Proposed resolution: 1. Remove these attributes be removed from the templates. 2. Add note that the client can use RefBaseObject::repository_container() (or what-ever its new name is) to obtain the instance for the enclosing extent. Implementation: The enclosing_package_ref attribute has been removed from the IDL templates and corresponding text in Section 5.8.2, “Package Module Template,” on page 5-46 and Section 5.8.6, “Class Tem-plate,” on page 5-54 and Section 5.8.10, “Association Template,” on page 5-60. The immediate_containing_package and outermost_containing_package operations have been added in Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5 and Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5 and in the RefBaseObject interface in Appendix B.2 “MOF IDL Summary”. Done [KR] Implementation: Deleted repository_container operation from RefBaseObject inter-face. Done. [SC] End of Annotations:===== Return-Path: From: Tom Digre To: issues Cc: MOF RTF , Boca RTF Subject: mof-rtf issue: IDL Generation, "enclosing_package_ref" redefiniti ons Date: Mon, 4 May 1998 12:33:06 -0400 MOF, ad/97-08-15 (boca-rtf copied due to BOCA dependency) Issue: The following items will cause illegal IDL redefinitions: * Package Template attribute "enclosing_package_ref", if packages are nested. (Section 7.3.1, page 7-8) * Type Template attribute "enclosing_package_ref", for any subtype. (Section 7.3.4, page 7-12). Tom Digre Return-Path: To: Tom Digre cc: MOF RTF , Boca RTF , crawley@dstc.edu.au Subject: Re: mof-rtf issue: IDL Generation, "enclosing_package_ref" redefiniti ons Date: Tue, 05 May 1998 13:06:20 +1000 From: Stephen Crawley Tom, You wrote: > The following items will cause illegal IDL redefinitions: > > * Package Template attribute "enclosing_package_ref", if > packages > are nested. (Section 7.3.1, page 7-8) In this case, I don't think you are correct. Suppose that we have the following package structure: package Base { package Outer { package Inner { }; }; }; The IDL generated according to the Package template will look like this: module Base { interface BasePackage; module Outer { interface OuterPackage; module Inner { interface InnerPackage; interface InnerPackageFactory { InnerPackage create_inner_package (); }; interface InnerPackage : Reflective::Package { readonly attribute OuterPackage enclosing_package_ref; }; }; interface OuterPackageFactory { OuterPackage create_outer_package (); }; interface OuterPackage : Reflective::Package { readonly attribute BasePackage enclosing_package_ref; readonly attribute Inner::InnerPackage inner_package_ref; }; }; interface BasePackageFactory { BasePackage create_base_package(); }; interface BasePackage : Reflective::Package { readonly attribute OuterPackage outer_package_ref; }; }; This looks like legal IDL to me that should compile without problems. In particular, the two 'enclosing_package_ref' attributes are in different scopes. But see below ... [***] > * Type Template attribute "enclosing_package_ref", for any > subtype. (Section 7.3.4, page 7-12). I think you have identified a problem ... assuming that by 'subtype' you mean something like: package Base { type T1 { }; type T2 : T1 { }; }; This will generate IDL like: module Base { interface BasePackage; ... interface T1Class { readonly attribute BasePackage enclosing_package_ref; ... }; ... interface T2Class : T1Class { readonly attribute BasePackage enclosing_package_ref; ... }; }; which is (as you say) illegal IDL. Fixing this is not a trivial matter. The syntax side could be fixed by changing "enclosing_package_ref" to "_ref", and by making sure that this is only generated if the enclosing package is not also the enclosing package for one of the type's supertype ancestors. But that leaves a messy semantic problem when one of the supertypes is defined in another package; e.g. package P1 { type T1 {}; }; package P2 { import P1; type T2 : P1::T1 {}; }; which leads to the "P2::T2Class" interface having two enclosing package references! interface T2Class : P1::T1Class { // inherited from P1::T1Class // readonly attribute P1::P1Package p1_package_ref; readonly attribute P2Package p2_package_ref; }; This is syntactically fine, but nonsense from the semantic point of view since any Class object has precisely one containing package! Since there is no way to stop the spurious "p1_package_ref" attribute from being inherited, there are two unpleasant choices: 1) Define the inherited 'ref' attribute to have a nil object reference as value. 2) Remove the 'enclosing_package_ref' attributes from the Package templates. The client can obtain the enclosing package by calling "Reflective::RefBaseObject.repository_container" and narrowing the resulting "RefBaseObject". Comments please on which of these would be preferable ... [***] I think a similar problem >>would<< occur for a packages. E.g. consider a package structure of the form: package Base { package Inner1 { }; package Inner2 : Inner1 { }; }; However, this case is precluded by section 7.4 which gives the following precondition for successful IDL generation: "A nested Package may not be used as a subtype or supertype" (Phew!) -- Steve Return-Path: From: Tom Digre To: Stephen Crawley Cc: MOF RTF , Boca RTF Subject: RE: mof-rtf issue: IDL Generation, "enclosing_package_ref" redefi niti ons Date: Tue, 5 May 1998 07:40:08 -0400 Stephen- Thanks for your comments, my responses below. Tom Digre > ---------- > From: Stephen Crawley[SMTP:crawley@dstc.edu.au] > Sent: Monday, May 04, 1998 11:06 PM > To: Tom Digre > Cc: MOF RTF; Boca RTF; crawley@dstc.edu.au > Subject: Re: mof-rtf issue: IDL Generation, > "enclosing_package_ref" redefiniti ons > > > Tom, > > You wrote: > > The following items will cause illegal IDL redefinitions: > > > > * Package Template attribute "enclosing_package_ref", if > packages > > are nested. (Section 7.3.1, page 7-8) > > In this case, I don't think you are correct. > Suppose that we have the following package structure: > > package Base { > package Outer { > package Inner { > }; > }; > }; > [Tom] This form is not an issue. As you note later, the issue is > with package subtyping. [deleted clarification of above] > But see below ... [***] > > > * Type Template attribute "enclosing_package_ref", for any > > subtype. (Section 7.3.4, page 7-12). > > I think you have identified a problem ... assuming that by 'subtype' > you > mean something like: > > package Base { > type T1 { > }; > > type T2 : T1 { > }; > }; > > This will generate IDL like: > > module Base { > interface BasePackage; > ... > interface T1Class { > readonly attribute BasePackage enclosing_package_ref; > ... > }; > ... > interface T2Class : T1Class { > readonly attribute BasePackage enclosing_package_ref; > ... > }; > }; > > which is (as you say) illegal IDL. > > Fixing this is not a trivial matter. The syntax side could be fixed > by > changing "enclosing_package_ref" to > "_ref", > and by making sure that this is only generated if the enclosing > package > is not also the enclosing package for one of the type's supertype > ancestors. > > But that leaves a messy semantic problem when one of the supertypes > is > defined in another package; e.g. > > package P1 { > type T1 {}; > }; > > package P2 { > import P1; > type T2 : P1::T1 {}; > }; > > which leads to the "P2::T2Class" interface having two enclosing > package > references! > > interface T2Class : P1::T1Class { > // inherited from P1::T1Class > // readonly attribute P1::P1Package p1_package_ref; > > readonly attribute P2Package p2_package_ref; > }; > > This is syntactically fine, but nonsense from the semantic point > of view since any Class object has precisely one containing > package! > > Since there is no way to stop the spurious "p1_package_ref" > attribute > from being inherited, there are two unpleasant choices: > > 1) Define the inherited 'ref' attribute to have a nil object > reference as value. > > 2) Remove the 'enclosing_package_ref' attributes from the Package > templates. The client can obtain the enclosing package by > calling "Reflective::RefBaseObject.repository_container" and > narrowing the resulting "RefBaseObject". > > Comments please on which of these would be preferable ... > [Tom] I prefer option 2. > [***] I think a similar problem >>would<< occur for a packages. E.g. > > consider a package structure of the form: > > package Base { > package Inner1 { > }; > package Inner2 : Inner1 { > }; > }; > > However, this case is precluded by section 7.4 which gives the > following precondition for successful IDL generation: > > "A nested Package may not be used as a subtype or supertype" > [Tom] I don't know why these "preconditions" for IDL generation do not align with the MOF model constraints, but that is another issue. What about this example: package Base{ }; package Base2:Base{ }; > (Phew!) > > -- Steve > >