Issue 15156: OCL 2.1 Parametric references (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection. Perhaps that the standard library support reflection more effectively with: self.oclGet(MyClass::a) Resolution: Revised Text: Actions taken: March 30, 2010: received issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUFAFDcsUvUnw4U/2dsb2JhbACPPotwccBLhQAE Date: Tue, 30 Mar 2010 19:14:05 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.1 Parametric references X-Plusnet-Relay: c84423e2371eee6cb2051ed87355e045 Hi OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection. Perhaps that the standard library support reflection more effectively with: self.oclGet(MyClass::a) Regards From: "Uhl, Axel" To: "ocl2-rtf@omg.org" CC: "Willink, Ed" Date: Tue, 27 Apr 2010 12:35:51 +0200 Subject: RE: [Issue 15156] - Parametric references Thread-Topic: [Issue 15156] - Parametric references Thread-Index: Acrl75yUE9rm5J3uTqe9TFtHNYPnEAAA0aGQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3RAPnP5021183 Hi Ed, context Tlocal::oclGet(OclProperty) : Tremote ... will be able to *type* the expression properly. So yes, if generics support were added to the OCL type system, we could make oclGet a type-safe operation (unless wildcards are permitted again, where I'm not sure if UML supports it; Java does and it often kills the whole idea of generics although with a generics system based on a legacy type system like in Java that's probably the best you can get...). However, it is in the nature of reflection that at compile time it is not possible to know which feature is being navigated. Therefore, even with generics in OCL it would still no longer be possible to analyze such expressions at compile time to understand which model changes may have an impact on the expression's value for which context objects. I think this is a severe drawback when you think about scaled-up applications of OCL where it is not easily possible to re-evaluate all expressions on all contexts all the time. When we employ OCL for semantic analysis of models during design time, I expect the same level of usability as we get it from modern tool environments (think Eclipse JDT). This means that re-validations not only have to happen locally where the change occurred, but probably in a much larger context (e.g., in the scope of the entire Eclipse workspace, like it happens to be implemented in JDT). This requires a good understanding of the navigation paths used in the OCL expressions. Using reflection kills this. Now you could argue that nobody is *forced* to use reflection, and I agree. And if we consider this discussion independently of the discussion of reverse-navigating a one-way reference using OCL then I'm only slightly opposed to this proposal, mostly because it'll make incremental re-evaluation and the up-front analysis significantly harder. By any means, the oclGet proposition that receives a Property as argument can't be a solution for reverse navigation because no Property element exists in an EMOF metamodel if there is no explicit opposite declared. For this, a "dual" operation would have to be introduced: context Tremote::oclGetOpposite(OclProperty) : Tlocal ... The same arguments about lack of compile-time analysis capabilities apply which is why I think that for reverse navigation we should rather be looking at an extension of the OCL AST, supporting something like OppositePropertyCallExp which makes most sense in the EMOF case for Property element that don't have an opposite Property defined. As discussed, e.g., in https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 the name for reverse navigation should be stored in an annotation on the Property. Best, -- Axel > > -----Original Message----- > > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > > Sent: 13 April 2010 11:25 > > To: ocl2-rtf@omg.org > > Subject: RE: Issue 15156 - Parametric references > > > > Hi Axel > > > > Interesting. > > > > Java, UML and Ecore have explicit generics. > > > > OCL currently has implicit generics: Collection(T), > > Collection(T1)::product(T2). > > > > The lack of explicit generics in OCL is a major failure in > > UML alignment, so > > OCL should be acquiring explicit generics as a bug fix rather than an > > enhancement. > > > > Ecore and Java generics were introduced at a time when the > > corresponding > > languages already had non-generic reflection, and so backward > > compatibility > > inhibited provision of generic reflection. This is not so for > > OCL for which > > generics, reflection and the run-time meta-model are all > > undefined or at > > least > > only defined by intuition. > > > > The signature of oclGet could be > > > > context > > Tlocal::oclGet(OclProperty) : Tremote ... > > > > Regards > > > > Ed Willink > > > > > -----Original Message----- > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > Sent: 13 April 2010 08:49 > > > To: ocl2-rtf@omg.org > > > Cc: Ed. Willink (ed@willink.me.uk) > > > Subject: Issue 15156 > > > > > > Hi, > > > > > > I understand where Ed is coming from, and yes, reflection can > > > be a powerful tool. We currently benefit a lot from OCL being > > > statically typed. With Ed's proposal, the following would > > be possible: > > > > > > let ref=if cond then > > > MyClass::a > > > else > > > MyClass::b > > > endif > > > in > > > self.oclGet(ref) > > > > > > The return type of oclGet would have to be OclAny. > > > > > > We're currently working on infrastructure that allows us to > > > derive from a model change event which OCL expressions may > > > have changed their value due to the change, and on which > > > context objects. For this, it is necessary to understand > > > across which references/associations an expression navigated. > > > By traversing those in reverse direction, we can find out > > > about the context objects for which the expression's value > > > may have changed. > > > > > > With OCL supporting reflection we would no longer be able to > > > determine the references/associations along which an > > > expression navigates. This in particular would kill this idea > > > of efficient incremental re-validation of OCL-specified > > > constraints which I think is essential to the scalable use of > > > OCL in practice. > > > > > > Best, > > > -- Axel > > > > > > > ************************************************************** > > ************** > > Please consider the environment before printing this email. > > Thales Research and Technology (UK) Limited DISCLAIMER: The > > information > > contained in this e-mail is confidential. It may also be legally > > privileged. It is intended only for the stated addressee(s) > > and access to > > it by any other person is unauthorised. If you are not an > > addressee, you > > must not disclose, copy, circulate or in any other way use or > > rely on the > > information contained herein. Such unauthorised use may be > > unlawful. We > > may monitor all e-mail communications through our networks. > > If you have > > received this e-mail in error, please inform us immediately > > on +44 (0)1293 > > 575987 and delete it and all copies from your system. We accept no > > responsibility for changes to any e-mail which occur after it > > has been sent. > > Attachments to this e-mail may contain software viruses which > > could damage > > your system. We therefore recommend you virus-check all > > attachments before > > opening. The registered office of Thales Research and Technology > (UK) > > Limited is at: 2 Dashwood Lang Road, The Bourne Business > > Park, Addlestone, > > Weybridge, Surrey KT15 2NX. Registered in England No. 774298. > > ************************************************************** > > ************** > > From: "Willink, Ed" To: "'Uhl, Axel'" , ocl2-rtf@omg.org Cc: "Willink, Ed" Subject: RE: [Issue 15156] - Parametric references Date: Tue, 27 Apr 2010 12:55:01 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Axel [Any comments you have on the principle of supporting reflection in OCL belong with Issue 14642. Once the principle has been resolved, it may be appropriate to establish quite where the boundary of decidability lies. I doubt that even without reflection, OCL is 100% decideable for the most obtuse overloading and redefinition of OclAny functionality.] If I advocated oclGet as the solution to opposite navigation elsewhere, that was a mistake. oclGet is the solution to parametric navigation. In context Tlocal::oclGet(OclProperty) : Tremote ... oclGet receives an OclProperty not a Property. Each OclProperty is the synthesized unification of one of: a) explicit meta-model Properties from EMOF/Ecore/UML/... b) inferred meta-model Properties (e.g. unnavigable opposites) from EMOF/Ecore (Issue 15175) c) defined Properties from CompleteOCL definitions (Issue 12854) d) OCL standard library properties (Issue 14861 problem 2) e) disambiguated association end (Issue 15220) Regards Ed Willink > -----Original Message----- > From: Uhl, Axel [mailto:axel.uhl@sap.com] > Sent: 27 April 2010 11:36 > To: ocl2-rtf@omg.org > Cc: Willink, Ed > Subject: RE: [Issue 15156] - Parametric references > > Hi Ed, > > context OclClassifier> Tlocal::oclGet(OclProperty) : > Tremote ... > > will be able to *type* the expression properly. So yes, if > generics support were added to the OCL type system, we could > make oclGet a type-safe operation (unless wildcards are > permitted again, where I'm not sure if UML supports it; Java > does and it often kills the whole idea of generics although > with a generics system based on a legacy type system like in > Java that's probably the best you can get...). > > However, it is in the nature of reflection that at compile > time it is not possible to know which feature is being > navigated. Therefore, even with generics in OCL it would > still no longer be possible to analyze such expressions at > compile time to understand which model changes may have an > impact on the expression's value for which context objects. I > think this is a severe drawback when you think about > scaled-up applications of OCL where it is not easily possible > to re-evaluate all expressions on all contexts all the time. > > When we employ OCL for semantic analysis of models during > design time, I expect the same level of usability as we get > it from modern tool environments (think Eclipse JDT). This > means that re-validations not only have to happen locally > where the change occurred, but probably in a much larger > context (e.g., in the scope of the entire Eclipse workspace, > like it happens to be implemented in JDT). This requires a > good understanding of the navigation paths used in the OCL > expressions. Using reflection kills this. > > Now you could argue that nobody is *forced* to use > reflection, and I agree. And if we consider this discussion > independently of the discussion of reverse-navigating a > one-way reference using OCL then I'm only slightly opposed to > this proposal, mostly because it'll make incremental > re-evaluation and the up-front analysis significantly harder. > > By any means, the oclGet proposition that receives a Property > as argument can't be a solution for reverse navigation > because no Property element exists in an EMOF metamodel if > there is no explicit opposite declared. For this, a "dual" > operation would have to be introduced: > > context OclClassifier> > Tremote::oclGetOpposite(OclProperty) : Tlocal ... > > The same arguments about lack of compile-time analysis > capabilities apply which is why I think that for reverse > navigation we should rather be looking at an extension of the > OCL AST, supporting something like OppositePropertyCallExp > which makes most sense in the EMOF case for Property element > that don't have an opposite Property defined. As discussed, > e.g., in https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 > the name for reverse navigation should be stored in an > annotation on the Property. > > Best, > -- Axel > > > > > > -----Original Message----- > > > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > > > Sent: 13 April 2010 11:25 > > > To: ocl2-rtf@omg.org > > > Subject: RE: Issue 15156 - Parametric references > > > > > > Hi Axel > > > > > > Interesting. > > > > > > Java, UML and Ecore have explicit generics. > > > > > > OCL currently has implicit generics: Collection(T), > > > Collection(T1)::product(T2). > > > > > > The lack of explicit generics in OCL is a major failure in > > > UML alignment, so > > > OCL should be acquiring explicit generics as a bug fix > rather than an > > > enhancement. > > > > > > Ecore and Java generics were introduced at a time when the > > > corresponding > > > languages already had non-generic reflection, and so backward > > > compatibility > > > inhibited provision of generic reflection. This is not so for > > > OCL for which > > > generics, reflection and the run-time meta-model are all > > > undefined or at > > > least > > > only defined by intuition. > > > > > > The signature of oclGet could be > > > > > > context OclClassifier> > > > Tlocal::oclGet(OclProperty) : Tremote ... > > > > > > Regards > > > > > > Ed Willink > > > > > > > -----Original Message----- > > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > > Sent: 13 April 2010 08:49 > > > > To: ocl2-rtf@omg.org > > > > Cc: Ed. Willink (ed@willink.me.uk) > > > > Subject: Issue 15156 > > > > > > > > Hi, > > > > > > > > I understand where Ed is coming from, and yes, reflection can > > > > be a powerful tool. We currently benefit a lot from OCL being > > > > statically typed. With Ed's proposal, the following would > > > be possible: > > > > > > > > let ref=if cond then > > > > MyClass::a > > > > else > > > > MyClass::b > > > > endif > > > > in > > > > self.oclGet(ref) > > > > > > > > The return type of oclGet would have to be OclAny. > > > > > > > > We're currently working on infrastructure that allows us to > > > > derive from a model change event which OCL expressions may > > > > have changed their value due to the change, and on which > > > > context objects. For this, it is necessary to understand > > > > across which references/associations an expression navigated. > > > > By traversing those in reverse direction, we can find out > > > > about the context objects for which the expression's value > > > > may have changed. > > > > > > > > With OCL supporting reflection we would no longer be able to > > > > determine the references/associations along which an > > > > expression navigates. This in particular would kill this idea > > > > of efficient incremental re-validation of OCL-specified > > > > constraints which I think is essential to the scalable use of > > > > OCL in practice. > > > > > > > > Best, > > > > -- Axel **************************************************************************** Please consider the environment before printing this email. Thales Research and Technology (UK) Limited DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained herein. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0)1293 575987 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. The registered office of Thales Research and Technology (UK) Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered in England No. 774298. **************************************************************************** From: "Uhl, Axel" To: "Willink, Ed" , "ocl2-rtf@omg.org" Date: Tue, 27 Apr 2010 14:22:55 +0200 Subject: RE: [Issue 15156] - Parametric references Thread-Topic: [Issue 15156] - Parametric references Thread-Index: AcrmAHrftK3tD0HqSpeP1RSVnN0neAAAkCuw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3RCCcaq005333 Ed, thanks for the clarification on the difference between OclProperty and Property. So, using oclGet with an OclProperty that is inferred based on a non-navigable opposite (which in EMOF means there is no Property for the navigation direction desired) is the reflective version of using an OppositePropertyCallExp as suggested by issue 15175. While I'm strongly in favor of 15175, I remain reluctant regarding this issue 15156. Thanks and best, -- Axel > -----Original Message----- > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > Sent: Tuesday, April 27, 2010 1:55 PM > To: Uhl, Axel; ocl2-rtf@omg.org > Cc: Willink, Ed > Subject: RE: [Issue 15156] - Parametric references > > Hi Axel > > [Any comments you have on the principle of supporting reflection in OCL > belong > with Issue 14642. Once the principle has been resolved, it may be > appropriate > to establish quite where the boundary of decidability lies. I doubt > that > even > without reflection, OCL is 100% decideable for the most obtuse > overloading > and redefinition of OclAny functionality.] > > If I advocated oclGet as the solution to opposite navigation elsewhere, > that > was a mistake. oclGet is the solution to parametric navigation. In > > context > Tlocal::oclGet(OclProperty) : Tremote ... > > oclGet receives an OclProperty not a Property. > > Each OclProperty is the synthesized unification of one of: > a) explicit meta-model Properties from EMOF/Ecore/UML/... > b) inferred meta-model Properties (e.g. unnavigable opposites) > from > EMOF/Ecore (Issue 15175) > c) defined Properties from CompleteOCL definitions (Issue 12854) > d) OCL standard library properties (Issue 14861 problem 2) > e) disambiguated association end (Issue 15220) > > Regards > > Ed Willink > > > -----Original Message----- > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > Sent: 27 April 2010 11:36 > > To: ocl2-rtf@omg.org > > Cc: Willink, Ed > > Subject: RE: [Issue 15156] - Parametric references > > > > Hi Ed, > > > > context > OclClassifier> Tlocal::oclGet(OclProperty) : > > Tremote ... > > > > will be able to *type* the expression properly. So yes, if > > generics support were added to the OCL type system, we could > > make oclGet a type-safe operation (unless wildcards are > > permitted again, where I'm not sure if UML supports it; Java > > does and it often kills the whole idea of generics although > > with a generics system based on a legacy type system like in > > Java that's probably the best you can get...). > > > > However, it is in the nature of reflection that at compile > > time it is not possible to know which feature is being > > navigated. Therefore, even with generics in OCL it would > > still no longer be possible to analyze such expressions at > > compile time to understand which model changes may have an > > impact on the expression's value for which context objects. I > > think this is a severe drawback when you think about > > scaled-up applications of OCL where it is not easily possible > > to re-evaluate all expressions on all contexts all the time. > > > > When we employ OCL for semantic analysis of models during > > design time, I expect the same level of usability as we get > > it from modern tool environments (think Eclipse JDT). This > > means that re-validations not only have to happen locally > > where the change occurred, but probably in a much larger > > context (e.g., in the scope of the entire Eclipse workspace, > > like it happens to be implemented in JDT). This requires a > > good understanding of the navigation paths used in the OCL > > expressions. Using reflection kills this. > > > > Now you could argue that nobody is *forced* to use > > reflection, and I agree. And if we consider this discussion > > independently of the discussion of reverse-navigating a > > one-way reference using OCL then I'm only slightly opposed to > > this proposal, mostly because it'll make incremental > > re-evaluation and the up-front analysis significantly harder. > > > > By any means, the oclGet proposition that receives a Property > > as argument can't be a solution for reverse navigation > > because no Property element exists in an EMOF metamodel if > > there is no explicit opposite declared. For this, a "dual" > > operation would have to be introduced: > > > > context > OclClassifier> > > Tremote::oclGetOpposite(OclProperty) : Tlocal ... > > > > The same arguments about lack of compile-time analysis > > capabilities apply which is why I think that for reverse > > navigation we should rather be looking at an extension of the > > OCL AST, supporting something like OppositePropertyCallExp > > which makes most sense in the EMOF case for Property element > > that don't have an opposite Property defined. As discussed, > > e.g., in https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 > > the name for reverse navigation should be stored in an > > annotation on the Property. > > > > Best, > > -- Axel > > > > > > > > > > -----Original Message----- > > > > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > > > > Sent: 13 April 2010 11:25 > > > > To: ocl2-rtf@omg.org > > > > Subject: RE: Issue 15156 - Parametric references > > > > > > > > Hi Axel > > > > > > > > Interesting. > > > > > > > > Java, UML and Ecore have explicit generics. > > > > > > > > OCL currently has implicit generics: Collection(T), > > > > Collection(T1)::product(T2). > > > > > > > > The lack of explicit generics in OCL is a major failure in > > > > UML alignment, so > > > > OCL should be acquiring explicit generics as a bug fix > > rather than an > > > > enhancement. > > > > > > > > Ecore and Java generics were introduced at a time when the > > > > corresponding > > > > languages already had non-generic reflection, and so backward > > > > compatibility > > > > inhibited provision of generic reflection. This is not so for > > > > OCL for which > > > > generics, reflection and the run-time meta-model are all > > > > undefined or at > > > > least > > > > only defined by intuition. > > > > > > > > The signature of oclGet could be > > > > > > > > context > OclClassifier> > > > > Tlocal::oclGet(OclProperty) : Tremote ... > > > > > > > > Regards > > > > > > > > Ed Willink > > > > > > > > > -----Original Message----- > > > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > > > Sent: 13 April 2010 08:49 > > > > > To: ocl2-rtf@omg.org > > > > > Cc: Ed. Willink (ed@willink.me.uk) > > > > > Subject: Issue 15156 > > > > > > > > > > Hi, > > > > > > > > > > I understand where Ed is coming from, and yes, reflection can > > > > > be a powerful tool. We currently benefit a lot from OCL being > > > > > statically typed. With Ed's proposal, the following would > > > > be possible: > > > > > > > > > > let ref=if cond then > > > > > MyClass::a > > > > > else > > > > > MyClass::b > > > > > endif > > > > > in > > > > > self.oclGet(ref) > > > > > > > > > > The return type of oclGet would have to be OclAny. > > > > > > > > > > We're currently working on infrastructure that allows us to > > > > > derive from a model change event which OCL expressions may > > > > > have changed their value due to the change, and on which > > > > > context objects. For this, it is necessary to understand > > > > > across which references/associations an expression navigated. > > > > > By traversing those in reverse direction, we can find out > > > > > about the context objects for which the expression's value > > > > > may have changed. > > > > > > > > > > With OCL supporting reflection we would no longer be able to > > > > > determine the references/associations along which an > > > > > expression navigates. This in particular would kill this idea > > > > > of efficient incremental re-validation of OCL-specified > > > > > constraints which I think is essential to the scalable use of > > > > > OCL in practice. > > > > > > > > > > Best, > > > > > -- Axel > > *********************************************************************** > ***** > Please consider the environment before printing this email. > Thales Research and Technology (UK) Limited DISCLAIMER: The > information > contained in this e-mail is confidential. It may also be legally > privileged. It is intended only for the stated addressee(s) and access > to > it by any other person is unauthorised. If you are not an addressee, > you > must not disclose, copy, circulate or in any other way use or rely on > the > information contained herein. Such unauthorised use may be unlawful. > We > may monitor all e-mail communications through our networks. If you > have > received this e-mail in error, please inform us immediately on +44 > (0)1293 > 575987 and delete it and all copies from your system. We accept no > responsibility for changes to any e-mail which occur after it has been > sent. > Attachments to this e-mail may contain software viruses which could > damage > your system. We therefore recommend you virus-check all attachments > before > opening. The registered office of Thales Research and Technology (UK) > Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, > Addlestone, > Weybridge, Surrey KT15 2NX. Registered in England No. 774298. > *********************************************************************** From: "Uhl, Axel" To: "ocl2-rtf@omg.org" CC: "Ed. Willink (ed@willink.me.uk)" Date: Tue, 13 Apr 2010 09:48:49 +0200 Subject: Issue 15156 Thread-Topic: Issue 15156 Thread-Index: Acra3cDp1gq6D5vuSLC/olery0ilkQ== Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {0A5A75FA-0DDD-4E96-AEE2-CF8E0C76D956} x-cr-hashedpuzzle: Bn4Y BwKL ISLE Iq/A KMIO LRdS LcPq LnUg L+ly NkDd SzrK TCRL TDjf Tx3b UAc/ Uknm;2;ZQBkAEAAdwBpAGwAbABpAG4AawAuAG0AZQAuAHUAawA7AG8AYwBsADIALQByAHQAZgBAAG8AbQBnAC4AbwByAGcA;Sosha1_v1;7;{0A5A75FA-0DDD-4E96-AEE2-CF8E0C76D956};YQB4AGUAbAAuAHUAaABsAEAAcwBhAHAALgBjAG8AbQA=;Tue, 13 Apr 2010 07:48:49 GMT;SQBzAHMAdQBlACAAMQA1ADEANQA2AA== acceptlanguage: en-US, de-DE X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3D7dDjY000492 Hi, I understand where Ed is coming from, and yes, reflection can be a powerful tool. We currently benefit a lot from OCL being statically typed. With Ed's proposal, the following would be possible: let ref=if cond then MyClass::a else MyClass::b endif in self.oclGet(ref) The return type of oclGet would have to be OclAny. We're currently working on infrastructure that allows us to derive from a model change event which OCL expressions may have changed their value due to the change, and on which context objects. For this, it is necessary to understand across which references/associations an expression navigated. By traversing those in reverse direction, we can find out about the context objects for which the expression's value may have changed. With OCL supporting reflection we would no longer be able to determine the references/associations along which an expression navigates. This in particular would kill this idea of efficient incremental re-validation of OCL-specified constraints which I think is essential to the scalable use of OCL in practice. Best, -- Axel From: "Willink, Ed" To: ocl2-rtf@omg.org Subject: RE: Issue 15156 - Parametric references Date: Tue, 13 Apr 2010 11:24:36 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Axel Interesting. Java, UML and Ecore have explicit generics. OCL currently has implicit generics: Collection(T), Collection(T1)::product(T2). The lack of explicit generics in OCL is a major failure in UML alignment, so OCL should be acquiring explicit generics as a bug fix rather than an enhancement. Ecore and Java generics were introduced at a time when the corresponding languages already had non-generic reflection, and so backward compatibility inhibited provision of generic reflection. This is not so for OCL for which generics, reflection and the run-time meta-model are all undefined or at least only defined by intuition. The signature of oclGet could be context Tlocal::oclGet(OclProperty) : Tremote ... Regards Ed Willink > -----Original Message----- > From: Uhl, Axel [mailto:axel.uhl@sap.com] > Sent: 13 April 2010 08:49 > To: ocl2-rtf@omg.org > Cc: Ed. Willink (ed@willink.me.uk) > Subject: Issue 15156 > > Hi, > > I understand where Ed is coming from, and yes, reflection can > be a powerful tool. We currently benefit a lot from OCL being > statically typed. With Ed's proposal, the following would be possible: > > let ref=if cond then > MyClass::a > else > MyClass::b > endif > in > self.oclGet(ref) > > The return type of oclGet would have to be OclAny. > > We're currently working on infrastructure that allows us to > derive from a model change event which OCL expressions may > have changed their value due to the change, and on which > context objects. For this, it is necessary to understand > across which references/associations an expression navigated. > By traversing those in reverse direction, we can find out > about the context objects for which the expression's value > may have changed. > > With OCL supporting reflection we would no longer be able to > determine the references/associations along which an > expression navigates. This in particular would kill this idea > of efficient incremental re-validation of OCL-specified > constraints which I think is essential to the scalable use of > OCL in practice. > > Best, > -- Axel > **************************************************************************** Please consider the environment before printing this email. Thales Research and Technology (UK) Limited DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained herein. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0)1293 575987 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. The registered office of Thales Research and Technology (UK) Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered in England No. 774298. **************************************************************************** From: "Willink, Ed" To: "'Uhl, Axel'" Cc: "'juergen@omg.org'" Subject: RE: Issue 15156 - Parametric references Date: Tue, 27 Apr 2010 11:28:31 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Axel > err... http://www.omg.org/issues/ocl2-rtf.html#Issue15156 > doesn't show your follow-up posting. Where do I find the RTF > follow-up postings to the original issue postings? The OMG Issue archives are very difficult to follow at the best of times. I guess this is still in Juergen's inbox. http://www.omg.org/archives/ocl2-rtf/ is much more readable. Ed **************************************************************************** Please consider the environment before printing this email. Thales Research and Technology (UK) Limited DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained herein. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0)1293 575987 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. The registered office of Thales Research and Technology (UK) Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered in England No. 774298. Ed Willink