Issue 4202: Abstract package (mof-rtf) Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: MOF-RTF issue: Abstract Package In MOF 1.3 there is a constraint which says that Package cannot have isAbstract attribute set to true. However, it does make sense to have abstract packages in MOF. One example of an abstract package could be a package containing some basic set of primitive datatypes which I would like to reuse in my models. There is no reason to instantiate this kind of package - the result of instantiation of this package would be nothing more than an empty package proxy object. Resolution: Revised Text: Actions taken: February 16, 2001: received issue December 3, 2001: closed issue; Duplicate or Merged Discussion: This issue is duplicated by Issue 3446 End of Annotations:===== From: Martin Matula To: "'issues@omg.org'" , "'mof-rtf@omg.org'" Subject: Abstract package Date: Fri, 16 Feb 2001 12:46:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-2" X-UIDL: +"Y!!iKa!!PZ>e9J#pd9 MOF-RTF issue: Abstract Package In MOF 1.3 there is a constraint which says that Package cannot have isAbstract attribute set to true. However, it does make sense to have abstract packages in MOF. One example of an abstract package could be a package containing some basic set of primitive datatypes which I would like to reuse in my models. There is no reason to instantiate this kind of package - the result of instantiation of this package would be nothing more than an empty package proxy object. Regards, Martin Matula (mailto:martin.matula@netbeans.com) tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR From: Martin Matula To: "MOF-RTF (E-mail)" Subject: Proposed resolution for issue 4202 Date: Wed, 11 Apr 2001 16:19:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" X-UIDL: D2%!!SP/!!Nm>!!Y\Y!! Hi, I was thinking about issue 4202 (allow abstract packages) and came to this: 1) we should remove constraint [C-44] (Package cannot be declared as abstract.) 2) change IDL generation rules so that PackageFactory will not be generated for abstract packages 3) I propose creating constraint saying that if a package (let's call it PA) imports another package (let's call it PB) and some class in package PA inherits from a class in PB, then PA has to be declared as abstract, because the definition of such a package is incomplete. 4) Abstract packages can be inherited, imported or clustered. In case of import, there is no controversy. In case of clustering and inheritance, I suggest the following: a) if an abstract package is inherited by a package, and the reason why the inherited package was declared as abstract remains also in it's subpackage (see number 3)), the subpackage has to be declared as abstract. b) if an abstract package is clustered by a package, and the reason why the clustered package was declared as abstract remains also in the clustering package, the clustering package has to be declared as abstract. Otherwise the clustered package (as a part of the clustering package) is handled as if it wasn't abstract. Does this make sense? (I don't see a need for more additional constraints, but it is pretty likely that I am missing something. :) I still need to get more familiar with the IDL mapping.) Martin Matula (mailto:martin.matula@netbeans.com) tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR Importance: Normal Subject: Re: Proposed resolution for issue 4202 To: Martin Matula Cc: "MOF-RTF (E-mail)" From: "Stephen Brodsky" Date: Wed, 11 Apr 2001 08:58:40 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM039/03/M/IBM(Release 5.0.6 |December 14, 2000) at 04/11/2001 09:56:10 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 5Gbd93h3e90B(e9YHmd9 Martin, I disagree that having one class extend another (#3) affects whether or not a package is abstract. That is an example of package dependency. An abstract package can't be instantiated, yet PA can be instantiated along with PB. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 Martin Matula on 04/11/2001 07:19:02 AM To: "MOF-RTF (E-mail)" cc: Subject: Proposed resolution for issue 4202 Hi, I was thinking about issue 4202 (allow abstract packages) and came to this: 1) we should remove constraint [C-44] (Package cannot be declared as abstract.) 2) change IDL generation rules so that PackageFactory will not be generated for abstract packages 3) I propose creating constraint saying that if a package (let's call it PA) imports another package (let's call it PB) and some class in package PA inherits from a class in PB, then PA has to be declared as abstract, because the definition of such a package is incomplete. 4) Abstract packages can be inherited, imported or clustered. In case of import, there is no controversy. In case of clustering and inheritance, I suggest the following: a) if an abstract package is inherited by a package, and the reason why the inherited package was declared as abstract remains also in it's subpackage (see number 3)), the subpackage has to be declared as abstract. b) if an abstract package is clustered by a package, and the reason why the clustered package was declared as abstract remains also in the clustering package, the clustering package has to be declared as abstract. Otherwise the clustered package (as a part of the clustering package) is handled as if it wasn't abstract. Does this make sense? (I don't see a need for more additional constraints, but it is pretty likely that I am missing something. :) I still need to get more familiar with the IDL mapping.) Martin Matula (mailto:martin.matula@netbeans.com) tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR From: Martin Matula To: "'Stephen Brodsky'" Cc: "MOF-RTF (E-mail)" , "Stephen Crawley (E-mail)" Subject: RE: Proposed resolution for issue 4202 Date: Thu, 12 Apr 2001 12:23:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-UIDL: V*c!!?pgd9<_+!!L@""! Hi Steve, you are right. Here is my updated proposal: 1) we should remove constraint [C-44] (Package cannot be declared as abstract.) 2) change IDL generation rules so that PackageFactory will not be generated for abstract packages 3) Abstract packages can be inherited, imported the same way as non-abstract packages. 4) In case of package clustering, there are two possibilities: a) add a constraint saying that abstract package cannot be clustered b) allow clustering and handle the clustered package (as a part of the clustering package) as if it wasn't abstract. I personally think that a) is better. Martin > -----Original Message----- > From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] > Sent: Wednesday, April 11, 2001 5:59 PM > To: Martin Matula > Cc: MOF-RTF (E-mail) > Subject: Re: Proposed resolution for issue 4202 > > > > Martin, > > I disagree that having one class extend another (#3) affects > whether or not > a package is abstract. That is an example of package dependency. An > abstract package can't be instantiated, yet PA can be > instantiated along > with PB. > > Thanks, > > -Steve > > Stephen A. Brodsky, Ph.D. > Software Architect > Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS > Internet Address: sbrodsky@us.ibm.com > Phone: 408.463.5659 > > > Martin Matula on 04/11/2001 07:19:02 AM > > To: "MOF-RTF (E-mail)" > cc: > Subject: Proposed resolution for issue 4202 > > > > Hi, > I was thinking about issue 4202 (allow abstract packages) and > came to this: > 1) we should remove constraint [C-44] (Package cannot be declared as > abstract.) > 2) change IDL generation rules so that PackageFactory will > not be generated > for abstract packages > 3) I propose creating constraint saying that if a package > (let's call it > PA) > imports another package (let's call it PB) and some class in > package PA > inherits from a class in PB, then PA has to be declared as abstract, > because > the definition of such a package is incomplete. > 4) Abstract packages can be inherited, imported or clustered. > In case of > import, there is no controversy. In case of clustering and > inheritance, I > suggest the following: > a) if an abstract package is inherited by a package, and > the reason > why the inherited package was declared as abstract remains > also in it's > subpackage (see number 3)), the subpackage has to be declared > as abstract. > b) if an abstract package is clustered by a package, and > the reason > why the clustered package was declared as abstract remains also in the > clustering package, the clustering package has to be declared > as abstract. > Otherwise the clustered package (as a part of the clustering > package) is > handled as if it wasn't abstract. > Does this make sense? > (I don't see a need for more additional constraints, but it is pretty > likely > that I am missing something. :) I still need to get more > familiar with the > IDL mapping.) > > Martin Matula (mailto:martin.matula@netbeans.com) > tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR > > > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Martin Matula cc: "'Stephen Brodsky'" , "MOF-RTF (E-mail)" , "Stephen Crawley (E-mail)" , crawley@dstc.edu.au Subject: Re: Proposed resolution for issue 4202 In-Reply-To: Message from Martin Matula of "Thu, 12 Apr 2001 12:23:59 +0200." <10F82FC788E0D311AB820060083EAE1E02290B58@mail.netbeans.com> Mime-Version: 1.0 Date: Thu, 12 Apr 2001 23:30:08 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: '2j!!aTN!!^e Here is my updated proposal: > 1) we should remove constraint [C-44] (Package cannot be declared as > abstract.) > 2) change IDL generation rules so that PackageFactory will not be generated > for abstract packages > 3) Abstract packages can be inherited, imported the same way as non-abstract > packages. > 4) In case of package clustering, there are two possibilities: > a) add a constraint saying that abstract package cannot be clustered > b) allow clustering and handle the clustered package (as a part of > the clustering package) as if it wasn't abstract. > I personally think that a) is better. > Martin > Can I throw another problem at you? Can an abstract Package be nested? If so, how does this effect the IDL mapping? Also, can an abstract Package contain a non-abstract Package, and what does this mean? -- Steve From: Martin Matula To: "'Stephen Crawley'" Cc: "'Stephen Brodsky'" , "MOF-RTF (E-mail)" Subject: RE: Proposed resolution for issue 4202 Date: Thu, 12 Apr 2001 17:33:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-UIDL: Aa'e9@(Ce9CD:e9hD?e9 Hi Steve, thanks for your questions. That reminds me: Can a nested package be clustered? There is no constraint saying that it cannot. I guess it should be added, otherwise we will have to define what will happen if I try to instantiate the package that clusters some nested package. Also there should be a constraint in Import class saying that only Package can have isClustered set to true (it doesn't make any sense to set isClustered for Classes to true). Or we can have just one constraint saying that only topmost packages can be clustered. In case of nesting of abstract packages I think we can take two approaches: 1) define a constraint that says that if topmost package is abstract then all its nested packages are abstract and if the topmost package is not abstract, then none of its nested packages can be abstract. In other words, isAbstract has effect only for topmost packages. 2) we will allow to have an abstract package nested into a non-abstract package. Then the semantics of such nesting would have to be the same as semantics of package import => the following lines in the package template would apply only to non-abstract packages: // for each public contained Package readonly attribute Package _ref; I would still disallow having non-abstract package nested into an abstract package. However, the second option doesn't make much sense to me so I would ragher go with 1), which is what I silently supposed when I was writing the proposal and forgot to write it :). Let me know your opinion on this please. Martin > -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: Thursday, April 12, 2001 3:30 PM > To: Martin Matula > Cc: 'Stephen Brodsky'; MOF-RTF (E-mail); Stephen Crawley (E-mail); > crawley@dstc.edu.au > Subject: Re: Proposed resolution for issue 4202 > > > > Martin, > > You wrote: > > Here is my updated proposal: > > 1) we should remove constraint [C-44] (Package cannot be declared as > > abstract.) > > 2) change IDL generation rules so that PackageFactory will > not be generated > > for abstract packages > > 3) Abstract packages can be inherited, imported the same > way as non-abstract > > packages. > > 4) In case of package clustering, there are two possibilities: > > a) add a constraint saying that abstract package cannot > be clustered > > b) allow clustering and handle the clustered package > (as a part of > > the clustering package) as if it wasn't abstract. > > I personally think that a) is better. > > Martin > > > > Can I throw another problem at you? Can an abstract Package > be nested? > If so, how does this effect the IDL mapping? Also, can an abstract > Package contain a non-abstract Package, and what does this mean? > > -- Steve > From: "Martin Matula" To: "Mof-Rtf@Omg.Org" Subject: issue 4202: abstract packages - proposal Date: Tue, 9 Oct 2001 17:22:33 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: GMkd9+0Oe94BA!!\B*e9 Here is my proposal for resolution of issue 4202: 1) remove constraint [C-44] (Package cannot be declared as abstract.) 2) change IDL generation rules so that PackageFactory will not be generated for abstract packages 3) Abstract packages can be inherited, imported the same way as non-abstract packages. 4) add a constraint saying that abstract package cannot be clustered 5) non-abstract package can be nested into an abstract package (it can be instantiated only by instantiating of some subpackage of its outermost package). 6) abstract package can be nested into a non-abstract package 7) Change the Package template for IDL mapping like this: // for each public *non-abstract* contained Package readonly attribute Package_ref; 8) If a package is abstract and isLeaf=true, no IDL will be generated for it => change the package module template like this: // if this Package has visibility of private or protected *or this package is both abstract and leaf*, // no IDL is generated for it module { If this proposal will be accepted, we should change PrimitiveTypes and CorbaIdlTypes packages to be abstract and leaf. Martin Matula (mailto:martin.matula@sun.com) tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR From: "Baisley, Donald E" To: Martin Matula , "Mof-Rtf@Omg.Org" Subject: RE: issue 4202: abstract packages - proposal Date: Tue, 9 Oct 2001 15:36:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: IHid9:7*e9gh0!!66\d9 Hi Martin, Setting isAbstract and isLeaf both to true seems a little weird. I don't see why we want either of these to be true for PrimitiveTypes. Models can import data types without any regard to the existence of an extent for the model of the data types. We don't need to care whether anyone wants to make a PrimitiveTypes extent. Also, we should not have any problem with someone specializing PrimitiveTypes. It causes no problem. And it might be the sensible thing to do for someone defining an extended package of primitive types. Regards, Don -----Original Message----- From: Martin Matula [mailto:martin.matula@sun.com] Sent: Tuesday, October 09, 2001 8:23 AM To: Mof-Rtf@Omg.Org Subject: issue 4202: abstract packages - proposal Here is my proposal for resolution of issue 4202: 1) remove constraint [C-44] (Package cannot be declared as abstract.) 2) change IDL generation rules so that PackageFactory will not be generated for abstract packages 3) Abstract packages can be inherited, imported the same way as non-abstract packages. 4) add a constraint saying that abstract package cannot be clustered 5) non-abstract package can be nested into an abstract package (it can be instantiated only by instantiating of some subpackage of its outermost package). 6) abstract package can be nested into a non-abstract package 7) Change the Package template for IDL mapping like this: // for each public *non-abstract* contained Package readonly attribute Package_ref; 8) If a package is abstract and isLeaf=true, no IDL will be generated for it => change the package module template like this: // if this Package has visibility of private or protected *or this package is both abstract and leaf*, // no IDL is generated for it module { If this proposal will be accepted, we should change PrimitiveTypes and CorbaIdlTypes packages to be abstract and leaf. Martin Matula (mailto:martin.matula@sun.com) tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR From: "Martin Matula" To: "Baisley, Donald E" , "Mof-Rtf@Omg.Org" References: Subject: Re: issue 4202: abstract packages - proposal Date: Wed, 10 Oct 2001 00:08:22 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: kXJ!!Hhnd9a?B!!#*Je9 I was suggesting this so we would not have to generate any IDL code for these packages. I agree that we can solve this differently (e.g. by providing an additional tag, or by saying that if a package is abstract and does not contain anything else for which IDL code is generated then also IDL code for this package is not generated, but this make the Package template more complicated - in case of Package inheritance it should handel cases when a package is a subpackage of a package that does not have a corresponding Package interface generated because of the reason above - if the package is leaf, you don't have this problem) It just does not make sense to me to generate empty package interfaces for packages that will never be instantiated. Martin ----- Original Message ----- From: "Baisley, Donald E" To: "Martin Matula" ; "Mof-Rtf@Omg.Org" Sent: Tuesday, October 09, 2001 10:36 PM Subject: RE: issue 4202: abstract packages - proposal > Hi Martin, > > Setting isAbstract and isLeaf both to true seems a little weird. I >don't > see why we want either of these to be true for PrimitiveTypes. >Models can > import data types without any regard to the existence of an extent >for the > model of the data types. We don't need to care whether anyone wants >to make > a PrimitiveTypes extent. Also, we should not have any problem with someone > specializing PrimitiveTypes. It causes no problem. And it might be >the > sensible thing to do for someone defining an extended package of >primitive > types. > > Regards, > Don > > -----Original Message----- > From: Martin Matula [mailto:martin.matula@sun.com] > Sent: Tuesday, October 09, 2001 8:23 AM > To: Mof-Rtf@Omg.Org > Subject: issue 4202: abstract packages - proposal > > > Here is my proposal for resolution of issue 4202: > > 1) remove constraint [C-44] (Package cannot be declared as > abstract.) > 2) change IDL generation rules so that PackageFactory will not be generated > for abstract packages > 3) Abstract packages can be inherited, imported the same way as non-abstract > packages. > 4) add a constraint saying that abstract package cannot be clustered > 5) non-abstract package can be nested into an abstract package (it >can be > instantiated only by instantiating of some subpackage of its >outermost > package). > 6) abstract package can be nested into a non-abstract package > 7) Change the Package template for IDL mapping like this: > > // for each public *non-abstract* contained Package > readonly attribute >Package_ref; > > 8) If a package is abstract and isLeaf=true, no IDL will be >generated for it > => change the package module template like this: > > // if this Package has visibility of private or protected *or this >package > is both abstract and leaf*, > // no IDL is generated for it > module { > > > If this proposal will be accepted, we should change PrimitiveTypes >and > CorbaIdlTypes packages to be abstract and leaf. > > Martin Matula (mailto:martin.matula@sun.com) > tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: "Mof-Rtf@Omg.Org" , crawley@dstc.edu.au Subject: Re: issue 4202: abstract packages - proposal In-Reply-To: Message from "Martin Matula" of "Tue, 09 Oct 2001 17:22:33 +0200." <024d01c150d6$38b3dea0$e74b9c81@praguenb> Mime-Version: 1.0 Date: Wed, 10 Oct 2001 23:14:35 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 5a&e92g>e9TX#e9:/Xd9 > Here is my proposal for resolution of issue 4202: > > 1) remove constraint [C-44] (Package cannot be declared as > abstract.) OK. > 2) change IDL generation rules so that PackageFactory will not be generated > for abstract packages OK. > 3) Abstract packages can be inherited, imported the same way as non-abstract > packages. OK to both. > 4) add a constraint saying that abstract package cannot be clustered OK. > 5) non-abstract package can be nested into an abstract package (it can be > instantiated only by instantiating of some subpackage of its outermost > package). OK, I guess. > 6) abstract package can be nested into a non-abstract package I'm not sure about this. Suppose the nested abstract Package has Constraints or Classes with Operations that refer to state in the abstract Package's containing Package. Then suppose that you inherit the abstract Package into a non-nested Package. In what context should the Constraints / Operations be executed? Actually, this uncertainty >>also<< exists if the nested Package is non-abstract. At one point there was (or was going to be) a Constraint to forbid inheriting nested Packages outside of their outermost enclosing Package. > 7) Change the Package template for IDL mapping like this: > > // for each public *non-abstract* contained Package > readonly attribute Package_ref; OK. Though if I'm correct about 6), only non-abstract nested Packages should be allowed anyway. > 8) If a package is abstract and isLeaf=true, no IDL will be generated for it > => change the package module template like this: > > // if this Package has visibility of private or protected *or this package > is both abstract and leaf*, > // no IDL is generated for it > module { This is definitely wrong. IDL must be generated for an abstract Package, even if it is declared as leaf. If we don't, then the IDL for the abstract Package's DataTypes and their collection types don't appear anywhere. One could suppress the interface, and possibly even the interfaces for contained Classes, but this introduces non-uniformity and possible problems. For example, what if one of the Classes contains a DataType or Exception? How can I declare this without at least the proxy interface for its parent Class? So I don't think we should even do this. > If this proposal will be accepted, we should change PrimitiveTypes and > CorbaIdlTypes packages to be abstract and leaf. I don't think that PrimitiveTypes and CorbaIdlTypes should be "leaf". There is nothing wrong with a metamodel inheriting these Packages. [Besides, you can't suppress their IDL ... see above.] I'd prefer not to use encourage people to use "leaf" and "root" in metamodels. IMO, the "leaf" and "root" attributes are bells and whistles, and I'm hoping we will have the courage to drop them from the MOF Model in the final MOF 2.0 Kernel submission. -- Steve From: "Martin Matula" To: "Stephen Crawley" Cc: "Mof-Rtf@Omg.Org" References: <200110101314.f9ADEVE02724@piglet.dstc.edu.au> Subject: Re: issue 4202: abstract packages - proposal Date: Wed, 10 Oct 2001 15:52:20 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: bBNe9F'#!!e63!!7,i!! Hi Steve, > > 6) abstract package can be nested into a non-abstract package > > I'm not sure about this. Suppose the nested abstract Package has > Constraints or Classes with Operations that refer to state in the > abstract Package's containing Package. Then suppose that you >inherit > the abstract Package into a non-nested Package. In what context >should > the Constraints / Operations be executed? > > Actually, this uncertainty >>also<< exists if the nested Package is > non-abstract. At one point there was (or was going to be) a >Constraint > to forbid inheriting nested Packages outside of their outermost > enclosing Package. I think that inheriting of nested packages should be allowed only for packages nested in the same outermost package or its subpackage. This should solve this problem. Other kinds of nested packages inheritance don't make sense to me. IMHO having a nested abstract package is very similar to having an imported package. Anyway, people can definitely live without abstract nested packages so I am not against forbiding them. > > 8) If a package is abstract and isLeaf=true, no IDL will be generated for it > > => change the package module template like this: > > > > // if this Package has visibility of private or protected *or this package > > is both abstract and leaf*, > > // no IDL is generated for it > > module { I take this back. I admit that this was a stupid idea... :) Thanks, Martin From: "Baisley, Donald E" To: Martin Matula , "Mof-Rtf@Omg.Org" Subject: RE: issue 4202: abstract packages - proposal Date: Wed, 10 Oct 2001 13:49:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )Rf!!HM8e9Y:(e96)md9 Hi Martin, Don't generate IDL for anything unless you have a reason. You don't need a tag to stop generation. Simply do not generate what you don't want. MOF is not tied to CORBA IDL. We don't know what the generation requirements might be for future language bindings. Being primitive in MOF does not imply a type is primitive in every language. So let's not let our IDL generation concerns lead us to make funny changes to our core metamodel. Enjoy, Don -----Original Message----- From: Martin Matula [mailto:martin.matula@sun.com] Sent: Tuesday, October 09, 2001 3:08 PM To: Baisley, Donald E; Mof-Rtf@Omg.Org Subject: Re: issue 4202: abstract packages - proposal Importance: High I was suggesting this so we would not have to generate any IDL code for these packages. I agree that we can solve this differently (e.g. by providing an additional tag, or by saying that if a package is abstract and does not contain anything else for which IDL code is generated then also IDL code for this package is not generated, but this make the Package template more complicated - in case of Package inheritance it should handel cases when a package is a subpackage of a package that does not have a corresponding Package interface generated because of the reason above - if the package is leaf, you don't have this problem) It just does not make sense to me to generate empty package interfaces for packages that will never be instantiated. Martin ----- Original Message ----- From: "Baisley, Donald E" To: "Martin Matula" ; "Mof-Rtf@Omg.Org" Sent: Tuesday, October 09, 2001 10:36 PM Subject: RE: issue 4202: abstract packages - proposal > Hi Martin, > > Setting isAbstract and isLeaf both to true seems a little weird. I >don't > see why we want either of these to be true for PrimitiveTypes. >Models can > import data types without any regard to the existence of an extent >for the > model of the data types. We don't need to care whether anyone wants >to make > a PrimitiveTypes extent. Also, we should not have any problem with someone > specializing PrimitiveTypes. It causes no problem. And it might be >the > sensible thing to do for someone defining an extended package of >primitive > types. > > Regards, > Don > > -----Original Message----- > From: Martin Matula [mailto:martin.matula@sun.com] > Sent: Tuesday, October 09, 2001 8:23 AM > To: Mof-Rtf@Omg.Org > Subject: issue 4202: abstract packages - proposal > > > Here is my proposal for resolution of issue 4202: > > 1) remove constraint [C-44] (Package cannot be declared as > abstract.) > 2) change IDL generation rules so that PackageFactory will not be generated > for abstract packages > 3) Abstract packages can be inherited, imported the same way as non-abstract > packages. > 4) add a constraint saying that abstract package cannot be clustered > 5) non-abstract package can be nested into an abstract package (it >can be > instantiated only by instantiating of some subpackage of its >outermost > package). > 6) abstract package can be nested into a non-abstract package > 7) Change the Package template for IDL mapping like this: > > // for each public *non-abstract* contained Package > readonly attribute >Package_ref; > > 8) If a package is abstract and isLeaf=true, no IDL will be >generated for it > => change the package module template like this: > > // if this Package has visibility of private or protected *or this >package > is both abstract and leaf*, > // no IDL is generated for it > module { > > > If this proposal will be accepted, we should change PrimitiveTypes >and > CorbaIdlTypes packages to be abstract and leaf. > > Martin Matula (mailto:martin.matula@sun.com) > tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR > From: "Martin Matula" To: Subject: issue 4202: abstract packages - revised proposal Date: Fri, 12 Oct 2001 15:11:14 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: jo`!!+GYd9%XN!!;Sk!! Hi all, here is my revised proposal for resolution of issue 4202. As we have decided to forbid inheritance of nested packages (because it would be more complicated to support in implementation than it is worth), I have simplified my proposal to look like this: 1) remove constraint [C-44] (Package cannot be declared as abstract.) 2) change IDL generation rules so that PackageFactory will not be generated for abstract packages 3) add a constraint saying that abstract package cannot be clustered Note: Abstract packages can be inherited and imported the same way as non-abstract packages. Martin X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: issue 4202: abstract packages Mime-Version: 1.0 Date: Thu, 18 Oct 2001 17:15:30 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: multipart/mixed ; boundary="==_Exmh_-14138527600" X-UIDL: 'L2e9d"5e9MJF!!PGI!! Folks, Here is a formal (with revised text etcetera) based on Martin's revised proposal from last week (message attached). Note: this resolution ASSUMES that we restrict inheritance and clustering of nested Packages as per the latest new issue. To avoid hassles, we should not vote on this one until the other one is up for vote. -- Steve > Source: Sun Microsystems (Mr. Martin Matula, martin.matula@netbeans.com) > Nature: Uncategorized Issue > Severity: > Summary: In MOF 1.3 there is a constraint which says that Package cannot > have isAbstract attribute set to true. However, it does make sense to have > abstract packages in MOF. One example of an abstract package could be a > package containing some basic set of primitive datatypes which I would > like to reuse in my models. There is no reason to instantiate this kind > of package - the result of instantiation of this package would be nothing > more than an empty package proxy object. Proposed resolution: Remove the Constraint [C-44] "Package cannot be declared as abstract". Add a new Constraint to the effect that abstract Packages cannot be clustered. Change the IDL mapping templates so that a PackageFactory interface is not generated for an abstract Package. Declare PrimitiveTypes and CorbaIdlTypes as abstrcact Packages. Proposed Revised Text: In section 3.3.1, add the following as the last sentence of paragraph 1. "The Model Package has "isAbstract", "isLeaf" and "isRoot" set to false." In section 3.4.23 "Package", under "Constraints", remove constraint [C-44] and under "IDL", remove the declaration for PACKAGES_CANNOT_BE_ABSTRACT. In section 3.4.24 "Import", under "Constraints" add: [Abstract Packages cannot be clustered [C-xx]] and under "IDL" add: const string ABSTRACT_PACKAGES_CANNOT_BE_CLUSTERED = "org.omg.mof:constraint.model.package.abstract_packages_cannot_be_clustered"; In section 3.9.4, on page 3-100, change the specification of [C-44] to read: [C-44] Then on page 3-100 (after the existing constraints), insert the following new Constraint: [C-xx] AbstractPackagesCannotBeClustered ... evaluation policy: immediate description: An abstract Package may not be clustered. context Import self.isClustered -> !self.imported.isAbstract In section 3.10, change the first sentence of the first paragraph to read: "The MOF defines an abstract Package calld PrimitiveTypes ..." and add the following as the second sentence of the second paragraph: "The PrimitiveTypes Package has "isAbstract" set to true, and "isLeaf" and "isRoot" set to false." In section 3.10.7, delete the IDL for the PrimitiveTypesPackageFactory interface and the comment lines that precede it (!!) In section 5.3.1, insert the following as the second sentence of the fourth paragraph (starting "The CorbaIdlTypes package is a ..."): "The CorbaIdlTypes Package has "isAbstract" set to true, and "isLeaf" and "isRoot" set to false." and then on page 5-10, delete the IDL for the CorbaIdlTypesPackageFactory interface and the comment lines that precede it. In 5.8.3, change the first sentence to read: "... is generated for top-level, non-abstract M2 level Packages only." and in the "Template" subsection, change: "// if the this Package is lop-level" (sic) to "// if this Package is top-level and non-abstract" Finally, update the XMI and IDL for the PrimitiveTypes and CorbaIdlTypes metamodels in the accompanying documents. Return-Path: omg-list-errors@emerald.omg.org Delivery-Date: Fri, 12 Oct 2001 23:12:52 +1000 Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id f9CDCgE08937; Fri, 12 Oct 2001 23:12:42 +1000 (EST) Received: from mercury.sun.com (hobbit.omg.org [192.67.184.3]) by emerald.omg.org (8.11.0/8.9.2) with ESMTP id f9CD4xe22585 for ; Fri, 12 Oct 2001 09:04:59 -0400 (EDT) Received: from mercury.sun.com (192.9.25.1) by hobbit.omg.org asmtp(1.1.1) id 5214; Fri, 12 Oct 2001 09:25:34 -0400 (EDT) Received: from sunpraha.Czech.Sun.COM ([129.156.76.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26802 for ; Fri, 12 Oct 2001 06:11:35 -0700 (PDT) Received: from matula (matula [129.156.75.132]) by sunpraha.Czech.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA14381 for ; Fri, 12 Oct 2001 15:11:33 +0200 (CEST) Message-ID: <012801c1531f$6ae5c820$844b9c81@matula> From: "Martin Matula" To: Subject: issue 4202: abstract packages - revised proposal Date: Fri, 12 Oct 2001 15:11:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) [] 1846 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Stephen Crawley cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: issue 4202: abstract packages - erratum In-Reply-To: Message from Stephen Crawley of "Thu, 18 Oct 2001 17:15:30 +1000." Mime-Version: 1.0 Date: Thu, 25 Oct 2001 13:42:15 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: *\#e9@&De9~~Td9%D>!! Whoops ... the OCL in this proposed resolution is wrong. It should read: self.isClustered implies !self.imported.isAbstract -- Steve