Issue 6399: UML 2 Super / Interfaces / Cannot nest classes in interfaces (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The Java spec says that it is legal to have Java Classes nested in Interfaces: 9.1.3 Interface Body and Member Declarations The body of an interface may declare members of the interface: InterfaceBody: { InterfaceMemberDeclarationsopt } InterfaceMemberDeclarations: InterfaceMemberDeclaration InterfaceMemberDeclarations InterfaceMemberDeclaration InterfaceMemberDeclaration: ConstantDeclaration AbstractMethodDeclaration ClassDeclaration InterfaceDeclaration ; But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML Resolution: see above Revised Text: Actions taken: October 31, 2003: received issue March 8, 2005: closed issue Discussion: The associations of Interface where the nestedClass needs to be inserted shows typos and omission of multiplicities, so we will fix those as well. The proposed resolution allows more than just Interfaces definitions to be nested in an Interface, but allows any kind of classifier to be nested. This is achieved by rerouting the Interface::nestedInterface association end from terminating on Interface to terminating on Classifier and changing its name to: Interface::nestedClassifier. New Diagram replaces figure 58 on page 112. Current Text Replace the following text in the Associations subsection New Text and Figure Add Classifier and a composition from Interface to Classifier ownedAttribute: Property[*] References all the properties owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature. ) ownedOperation: Operation[*] References all the operations owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature.) nestedClassifier: Classifier[*] References all the Classifiers owned by this Interface. (Subsets Namespace.ownedMember.) redefinedInterface: Interface[*] References all the Interfaces redefined by this Interface. (Subsets Element.redefinedElement.) End of Annotations:===== ubject: UML 2 Super / Interfaces / Cannot nest classes in interfaces X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 31 Oct 2003 20:21:27 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/31/2003 20:21:29, Serialize complete at 10/31/2003 20:21:29 The Java spec says that it is legal to have Java Classes nested in Interfaces: 9.1.3 Interface Body and Member Declarations The body of an interface may declare members of the interface: InterfaceBody: { InterfaceMemberDeclarationsopt } InterfaceMemberDeclarations: InterfaceMemberDeclaration InterfaceMemberDeclarations InterfaceMemberDeclaration InterfaceMemberDeclaration: ConstantDeclaration AbstractMethodDeclaration ClassDeclaration InterfaceDeclaration ; But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, "Karl Frank" Subject: Two resolutions for Ballot 21 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 27 Jul 2004 20:12:50 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/27/2004 20:12:53 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran Resolutions.6399.6630.040727.doc OMG Issue No: 6399 Title: UML 2 Super / Interfaces / Cannot nest classes in interfaces Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The Java spec says that it is legal to have Java Classes nested in Interfaces: 9.1.3 Interface Body and Member Declarations The body of an interface may declare members of the interface: InterfaceBody: { InterfaceMemberDeclarationsopt } InterfaceMemberDeclarations: InterfaceMemberDeclaration InterfaceMemberDeclarations InterfaceMemberDeclaration InterfaceMemberDeclaration: ConstantDeclaration AbstractMethodDeclaration ClassDeclaration InterfaceDeclaration ; But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML Discussion: The proposed resolution allows more than just Interfaces definitions to be nested in an Interface, but allows any kind of classifier to be nested. This is achieved by rerouting the Interface::nestedInterface association end from terminating on Interface to terminating on Classifier and changing its name to: Interface::nestedClassifier. This is shown in the diagram below that should replace figure 58 on page 112. Disposition: Resolved Subject: RE: Two resolutions for Ballot 21 Date: Tue, 27 Jul 2004 19:11:34 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two resolutions for Ballot 21 Thread-Index: AcR0N6JFeA+ywGT7T0KjqwVhqrOTvgAD/lBg From: "Karl Frank" To: "Branislav Selic" , , X-OriginalArrivalTime: 28 Jul 2004 02:11:40.0776 (UTC) FILETIME=[38827E80:01C47448] As a matter of principle I prefer the generality of your proposal, so am inclined to vote for that, but am concerned that Classifier is so general a modelElement it may have some odd and unexpected consequences to enable an interface to nest any kind of Classifier. If we go with your proposal, we will also need the revised text for the nestedClassifier association of Interface. My proposal fixes the missing multiplicities and a typo in the text for Interface attributes, as a passing gesture while adding the needed nested Interface - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran Subject: Merged resolution for Ballot 21 Date: Tue, 27 Jul 2004 20:44:22 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Merged resolution for Ballot 21 Thread-Index: AcR0N6JFeA+ywGT7T0KjqwVhqrOTvgAHT++Q From: "Karl Frank" To: "Branislav Selic" , , X-OriginalArrivalTime: 28 Jul 2004 03:44:33.0611 (UTC) FILETIME=[322DA1B0:01C47455] As I said in earlier, I like the idea of generalizing to Classifier. In the attached I have merged our two oroposed resolutions to combine the advantages of both. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran Merged_Issue_6399.doc OMG Issue No: 6399 Title: UML 2 Super / Interfaces / Cannot nest classes in interfaces Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The Java spec says that it is legal to have Java Classes nested in Interfaces: 9.1.3 Interface Body and Member Declarations The body of an interface may declare members of the interface: InterfaceBody: { InterfaceMemberDeclarationsopt } InterfaceMemberDeclarations: InterfaceMemberDeclaration InterfaceMemberDeclarations InterfaceMemberDeclaration InterfaceMemberDeclaration: ConstantDeclaration AbstractMethodDeclaration ClassDeclaration InterfaceDeclaration ; But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML Discussion: The associations of Interface where the nestedClass needs to be inserted shows typos and omission of multiplicities, so we will fix those as well. The proposed resolution allows more than just Interfaces definitions to be nested in an Interface, but allows any kind of classifier to be nested. This is achieved by rerouting the Interface::nestedInterface association end from terminating on Interface to terminating on Classifier and changing its name to: Interface::nestedClassifier. New Diagram replaces figure 58 on page 112. Current Text Replace the following text in the Associations subsection New Text and Figure Add Classifier and a composition from Interface to Classifier ownedAttribute: Property[*] References all the properties owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature. ) ownedOperation: Operation[*] References all the operations owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature.) nestedClassifier: Classifier[*] References all the Classifiers owned by this Interface. (Subsets Namespace.ownedMember.) redefinedInterface: Interface[*] References all the Interfaces redefined by this Interface. (Subsets Element.redefinedElement.) Disposition: Resolved From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Date: Thu, 29 Jul 2004 21:59:05 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments... 6399: Why don't we just add an association Classifier.nestedClassifier, rather than making this association explicit in all subtypes? This potentially makes sense in all the classifiers we have... Looking through the list: Class: nestedClassifier Behavior, Interaction, Statemachine, Usecase, Activity all inherited nestedClassifier from Class Interface: nestedClassifier (added by this proposal) Artifact: nestedArtifact Node: nestedNode (redefined) Without ability to nest classifier: Actor Datatype However, I can also see situations where you would want a Datatype to be defined using nested classifier definitions. 6401: As I already stated, there seems no reason to add this link as it just establishes another questionable twodirectional dependency between metaclasses. "Operation.class" is also questionable. Without having a good justification why this dependency should be added (other than symmetry reasons), we should hold back. 7370: Conrad pointed out that there could be functions matching the syntactic definition of constructors which do not create new data (which is one reading of constructor). So it is better to tune the first sentence in the proposed solution (submitted by me) to "A constructor has a single return result parameter of the type of the owning class". Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 29, 2004 6:02 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 21 -- please review and provide feedback if you have it It's been hard to keep track of who has proposed what for ballot 21. So, it is likely that this draft may have some omissions or, possibly, outdated versions of the many resolutions that have been flying about. Please do have a good look at it -- there are only 12 resolutions on the ballot (slim pickings this time around!). Thanks, Bran Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Date: Fri, 30 Jul 2004 07:41:06 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of ballot 21 -- please review and provide feedback if you have it Thread-Index: AcR2ENf7NuocwL89RDaTb8OTTu/ncQAL+PWA From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , , X-OriginalArrivalTime: 30 Jul 2004 14:41:08.0487 (UTC) FILETIME=[402E2970:01C47643] Thomas: One answer to your question: "Why not (add .nestedClassifier way up at the Classifier level)?" is that it goes way beyond what was required to resolve the issue. We have no review comments saying the reviewers saw a need to nest every possible kind of classifier in any classifier. Another answer is that it would require changing more diagrams and deleting associations from many more class descriptions. I am only marginally comfortable with adding nestedClassifier to Interface. My first proposal on 6399 only addedthe Interface.nestedClass that is required to meet the objection raised in 6399, and if I had been around in U2P days I would have advocated Class.nestedClass instead of the current Class.nestedClassifier We already have logged issues against the current permission to have operations in datatypes, it seems so odd to most people. To allow any kind of Classifier to be defined in the scope of a datatyps is even more strange, given the general sense of what datatypes are and are used for. So, yet a third answer to your question is, We would then have to deal with a flood of issues calling for constraining these things away in this or that branch of the heirarchy rooted in Classifier. - regards, Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, July 29, 2004 10:59 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Bran, comments... 6399: Why don't we just add an association Classifier.nestedClassifier, rather than making this association explicit in all subtypes? This potentially makes sense in all the classifiers we have... Looking through the list: Class: nestedClassifier Behavior, Interaction, Statemachine, Usecase, Activity all inherited nestedClassifier from Class Interface: nestedClassifier (added by this proposal) Artifact: nestedArtifact Node: nestedNode (redefined) Without ability to nest classifier: Actor Datatype However, I can also see situations where you would want a Datatype to be defined using nested classifier definitions. 6401: As I already stated, there seems no reason to add this link as it just establishes another questionable twodirectional dependency between metaclasses. "Operation.class" is also questionable. Without having a good justification why this dependency should be added (other than symmetry reasons), we should hold back. 7370: Conrad pointed out that there could be functions matching the syntactic definition of constructors which do not create new data (which is one reading of constructor). So it is better to tune the first sentence in the proposed solution (submitted by me) to "A constructor has a single return result parameter of the type of the owning class". Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 29, 2004 6:02 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 21 -- please review and provide feedback if you have it It's been hard to keep track of who has proposed what for ballot 21. So, it is likely that this draft may have some omissions or, possibly, outdated versions of the many resolutions that have been flying about. Please do have a good look at it -- there are only 12 resolutions on the ballot (slim pickings this time around!). Thanks, Bran From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , , Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Date: Fri, 30 Jul 2004 09:48:28 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, we cannot always just solve issues by making minor changes that in the end result in a big patchwork. Sometimes one needs to take a step back and ask what the real of a feature was, and whether a more systematic change is better. In this case, we have just about every classifier allowing nested classifiers (some redefining the notion for class to be more specific). We only have few cases where this is not. So when you decide to change yet another, this is the point to step back and ask whether there is not a general relationship at work here. If this is to big an undertaking, then it is better to defer the issue. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, July 30, 2004 9:41 AM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Thomas: One answer to your question: "Why not (add .nestedClassifier way up at the Classifier level)?" is that it goes way beyond what was required to resolve the issue. We have no review comments saying the reviewers saw a need to nest every possible kind of classifier in any classifier. Another answer is that it would require changing more diagrams and deleting associations from many more class descriptions. I am only marginally comfortable with adding nestedClassifier to Interface. My first proposal on 6399 only addedthe Interface.nestedClass that is required to meet the objection raised in 6399, and if I had been around in U2P days I would have advocated Class.nestedClass instead of the current Class.nestedClassifier We already have logged issues against the current permission to have operations in datatypes, it seems so odd to most people. To allow any kind of Classifier to be defined in the scope of a datatyps is even more strange, given the general sense of what datatypes are and are used for. So, yet a third answer to your question is, We would then have to deal with a flood of issues calling for constraining these things away in this or that branch of the heirarchy rooted in Classifier. - regards, Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, July 29, 2004 10:59 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Bran, comments... 6399: Why don't we just add an association Classifier.nestedClassifier, rather than making this association explicit in all subtypes? This potentially makes sense in all the classifiers we have... Looking through the list: Class: nestedClassifier Behavior, Interaction, Statemachine, Usecase, Activity all inherited nestedClassifier from Class Interface: nestedClassifier (added by this proposal) Artifact: nestedArtifact Node: nestedNode (redefined) Without ability to nest classifier: Actor Datatype However, I can also see situations where you would want a Datatype to be defined using nested classifier definitions. From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , , Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Date: Fri, 30 Jul 2004 09:52:44 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) This is an issue that has been specifically discussed several times. There are many data types with operations in practice, so that issue should just be closed. Whether you can have nested type definitions in data types is also not strange at all. SDL, for example, allows such, as does Eiffel. Why would you think that a nested classifier definition inside a data type is strange? A nested classifier definition is just an issue of visibility. There is a classifier needed for the data type to work, but the designer of that data type did not want this "utility" classifier to be visible outside. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, July 30, 2004 9:41 AM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it We already have logged issues against the current permission to have operations in datatypes, it seems so odd to most people. To allow any kind of Classifier to be defined in the scope of a datatyps is even more strange, given the general sense of what datatypes are and are used for. To: "Thomas Weigert" Cc: "Karl Frank" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 30 Jul 2004 11:51:04 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/30/2004 11:51:05, Serialize complete at 07/30/2004 11:51:05 In my view, it is not a good idea to use a small issue to solve a big one, even if the small issue is a symptom of a bigger one. The appropriate solution is to raise the big issue as a separate issue. In this case, I very strongly support Karl's current resolution because of some very practical concerns. The problem with the current spec is that it does not allow classes to be defined in an interface. Unfortunately, Java can do that, so we have an immediate problem; i.e., UML 2 cannot be sued to model one of the most commonly used OO languages. This is an immediate short-term problem that cannot wait for a long-term resolution. Deferring this issue is not a good thing for UML 2.0. Bran "Thomas Weigert" 07/30/2004 10:48 AM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Draft of ballot 21 -- please review and provide feedback if you have it Karl, we cannot always just solve issues by making minor changes that in the end result in a big patchwork. Sometimes one needs to take a step back and ask what the real of a feature was, and whether a more systematic change is better. In this case, we have just about every classifier allowing nested classifiers (some redefining the notion for class to be more specific). We only have few cases where this is not. So when you decide to change yet another, this is the point to step back and ask whether there is not a general relationship at work here. If this is to big an undertaking, then it is better to defer the issue. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, July 30, 2004 9:41 AM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Thomas: One answer to your question: "Why not (add .nestedClassifier way up at the Classifier level)?" is that it goes way beyond what was required to resolve the issue. We have no review comments saying the reviewers saw a need to nest every possible kind of classifier in any classifier. Another answer is that it would require changing more diagrams and deleting associations from many more class descriptions. I am only marginally comfortable with adding nestedClassifier to Interface. My first proposal on 6399 only addedthe Interface.nestedClass that is required to meet the objection raised in 6399, and if I had been around in U2P days I would have advocated Class.nestedClass instead of the current Class.nestedClassifier We already have logged issues against the current permission to have operations in datatypes, it seems so odd to most people. To allow any kind of Classifier to be defined in the scope of a datatyps is even more strange, given the general sense of what datatypes are and are used for. So, yet a third answer to your question is, We would then have to deal with a flood of issues calling for constraining these things away in this or that branch of the heirarchy rooted in Classifier. - regards, Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, July 29, 2004 10:59 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Bran, comments... 6399: Why don't we just add an association Classifier.nestedClassifier, rather than making this association explicit in all subtypes? This potentially makes sense in all the classifiers we have... Looking through the list: Class: nestedClassifier Behavior, Interaction, Statemachine, Usecase, Activity all inherited nestedClassifier from Class Interface: nestedClassifier (added by this proposal) Artifact: nestedArtifact Node: nestedNode (redefined) Without ability to nest classifier: Actor Datatype However, I can also see situations where you would want a Datatype to be defined using nested classifier definitions. To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 30 Jul 2004 12:44:59 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/30/2004 12:45:00, Serialize complete at 07/30/2004 12:45:00 Thanks, Thomas. I wish everyone on the FTF scrutinized the ballots as carefully as you. Feedback on your comments is below: > 6399: Why don't we just add an association Classifier. > nestedClassifier, rather than making this association explicit in > all subtypes? This potentially makes sense in all the classifiers we have... > > Looking through the list: > Class: nestedClassifier > Behavior, Interaction, Statemachine, Usecase, Activity all inherited > nestedClassifier from Class > Interface: nestedClassifier (added by this proposal) > Artifact: nestedArtifact > Node: nestedNode (redefined) > > Without ability to nest classifier: > Actor > Datatype > > However, I can also see situations where you would want a Datatype > to be defined using nested classifier definitions. Please see my previous response to this point. I want to make sure that we have a solution for an immediate hot problem that decouples us from theological arguments about whether Artifact::nestedArtifact and Interface::nestedClassifier are the same thing or whether Actor::nestedClassifier makes sense. > 6401: As I already stated, there seems no reason to add this link as > it just establishes another questionable twodirectional dependency > between metaclasses. "Operation.class" is also questionable. Without > having a good justification why this dependency should be added > (other than symmetry reasons), we should hold back. On this point, please note that at the highest level of abstraction, a Feature has access to the Classifier that it is a feature of (see figure 28 in the FAS). Therefore, the architectural-level intent is there and this particular resolution conforms to that intent that was clearly violated in this case. Again, we could argue whether this was a good architectural decision, but that is likely a longer-term discussion. > 7370: Conrad pointed out that there could be functions matching the > syntactic definition of constructors which do not create new data > (which is one reading of constructor). So it is better to tune the > first sentence in the proposed solution (submitted by me) to "A > constructor has a single return result parameter of the type of the > owning class". I will make this fix. Thanks...Bran