Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [OCL] Resolving properties, ambiguities
| [OCL] Resolving properties, ambiguities [message #56539] |
Wed, 04 October 2006 16:55  |
 Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi,
The current EMFT OCL implementation (R1_0_maintenance branch only) excludes
'explicitly defined iterator variables' as a source of a
property. It is done by design, as a result of the fix
https://bugs.eclipse.org/bugs/show_bug.cgi?id=151234.
While reading OCL 2.0 spec, I found myself in doubt, whether the spec
clearly states this.
There is section '7.8 Resolving properties', which describes how implicit
iterator properties are handled.
On the other hand, the section '9.3 Concrete Syntax' contains
AttributeCallExpCS and
Disambiguating rules:
[1] [A, B] 'simpleName' is name of an Attribute of the type of source or if
source is empty the name of an attribute of 'self'
or any of the iterator variables in (nested) scope.
So, it looks to me, that the resolution rule 'the most-inner-scope first'
should be used also if an iterator variable is not implicit.
To be accurate, the OCL expression bellow illustrates this topic.
context ecore::EPackage
eClassifiers->collect(classifier | name)
Should the result collect the package name or EClassifiers names?
Regards,
/Radek
|
|
|
| Re: [OCL] Resolving properties, ambiguities [message #56648 is a reply to message #56539] |
Wed, 04 October 2006 21:08  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
I would tend to follow (and actually did, as you indicated) the guidance of
the discussion in chapter 7 about resolving the source of implicit feature
calls. There are two problems with section 9.3:
- none of the Concrete Syntax (chapter 9) has been updated to match
the changes in the Abstract Syntax (chapter 8) in the latest draft
of the spec, and is incorrect in some areas as a result (no null
literal, still aligned with UML 1.4, etc.). The concrete syntax is
now 3 years old by my reckoning
- the disambiguating rule on the AttributeCallExpCS does not indicate
whether the iterator variables take precedence over self or vice versa
(remember that bug? :-)
So, I would answer that your example should collect the same package name
for every classifier. The convenience of syntactic shortcuts should be
exploited to the fullest ("eClassifiers->collect(name)" or even
"eClassifiers.name") or not at all ("eClassifiers->collect(c | c.name)").
A better answer would be: this issue should be raised with the OMG to
clarify the resolution of implicit source variables (if it isn't already on
the RTF's issues list). If you raise a bug on EMFT OCL, I'll see what can
be done in OMG.
Cheers,
Christian
Radek Dvorak wrote:
> Hi,
>
> The current EMFT OCL implementation (R1_0_maintenance branch only)
> excludes 'explicitly defined iterator variables' as a source of a
> property. It is done by design, as a result of the fix
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=151234.
> While reading OCL 2.0 spec, I found myself in doubt, whether the spec
> clearly states this.
>
> There is section '7.8 Resolving properties', which describes how implicit
> iterator properties are handled.
> On the other hand, the section '9.3 Concrete Syntax' contains
> AttributeCallExpCS and
> Disambiguating rules:
> [A, B] 'simpleName' is name of an Attribute of the type of source or
> [if
> source is empty the name of an attribute of 'self'
> or any of the iterator variables in (nested) scope.
>
> So, it looks to me, that the resolution rule 'the most-inner-scope first'
> should be used also if an iterator variable is not implicit.
>
> To be accurate, the OCL expression bellow illustrates this topic.
>
> context ecore::EPackage
> eClassifiers->collect(classifier | name)
>
> Should the result collect the package name or EClassifiers names?
>
> Regards,
> /Radek
|
|
|
| Re: [OCL] Resolving properties, ambiguities [message #56675 is a reply to message #56648] |
Wed, 04 October 2006 23:07 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Thanks, for the answer.
As for the precedence problem, there is another section (though in that
non-trustable area ;))
'9.1 Structure of the Concrete Syntax/Disambiguating rules', which mentions
the precedence in my opinion.
Right, it's just an example, but '7.8 Resolv...' is nothing more.
Actually, that is why I have raised this question at all, as in this rule it
is stated 'all iterator variables'.
I even see these two cases as not mutally exclusive, but I did not have the
knowledge that I should not use
chapter 9 ;)
I can see it's really an issue for OMG. Not easy to use such specifications
:(
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:eg17ri$ef3$1@utils.eclipse.org...
>
> Hi, Radek,
>
> I would tend to follow (and actually did, as you indicated) the guidance
> of
> the discussion in chapter 7 about resolving the source of implicit feature
> calls. There are two problems with section 9.3:
>
> - none of the Concrete Syntax (chapter 9) has been updated to match
> the changes in the Abstract Syntax (chapter 8) in the latest draft
> of the spec, and is incorrect in some areas as a result (no null
> literal, still aligned with UML 1.4, etc.). The concrete syntax is
> now 3 years old by my reckoning
> - the disambiguating rule on the AttributeCallExpCS does not indicate
> whether the iterator variables take precedence over self or vice versa
> (remember that bug? :-)
>
> So, I would answer that your example should collect the same package name
> for every classifier. The convenience of syntactic shortcuts should be
> exploited to the fullest ("eClassifiers->collect(name)" or even
> "eClassifiers.name") or not at all ("eClassifiers->collect(c | c.name)").
>
> A better answer would be: this issue should be raised with the OMG to
> clarify the resolution of implicit source variables (if it isn't already
> on
> the RTF's issues list). If you raise a bug on EMFT OCL, I'll see what can
> be done in OMG.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi,
>>
>> The current EMFT OCL implementation (R1_0_maintenance branch only)
>> excludes 'explicitly defined iterator variables' as a source of a
>> property. It is done by design, as a result of the fix
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=151234.
>> While reading OCL 2.0 spec, I found myself in doubt, whether the spec
>> clearly states this.
>>
>> There is section '7.8 Resolving properties', which describes how implicit
>> iterator properties are handled.
>> On the other hand, the section '9.3 Concrete Syntax' contains
>> AttributeCallExpCS and
>> Disambiguating rules:
>> [A, B] 'simpleName' is name of an Attribute of the type of source or
>> [if
>> source is empty the name of an attribute of 'self'
>> or any of the iterator variables in (nested) scope.
>>
>> So, it looks to me, that the resolution rule 'the most-inner-scope first'
>> should be used also if an iterator variable is not implicit.
>>
>> To be accurate, the OCL expression bellow illustrates this topic.
>>
>> context ecore::EPackage
>> eClassifiers->collect(classifier | name)
>>
>> Should the result collect the package name or EClassifiers names?
>>
>> Regards,
>> /Radek
>
|
|
|
| Re: [OCL] Resolving properties, ambiguities [message #593709 is a reply to message #56539] |
Wed, 04 October 2006 21:08 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
I would tend to follow (and actually did, as you indicated) the guidance of
the discussion in chapter 7 about resolving the source of implicit feature
calls. There are two problems with section 9.3:
- none of the Concrete Syntax (chapter 9) has been updated to match
the changes in the Abstract Syntax (chapter 8) in the latest draft
of the spec, and is incorrect in some areas as a result (no null
literal, still aligned with UML 1.4, etc.). The concrete syntax is
now 3 years old by my reckoning
- the disambiguating rule on the AttributeCallExpCS does not indicate
whether the iterator variables take precedence over self or vice versa
(remember that bug? :-)
So, I would answer that your example should collect the same package name
for every classifier. The convenience of syntactic shortcuts should be
exploited to the fullest ("eClassifiers->collect(name)" or even
"eClassifiers.name") or not at all ("eClassifiers->collect(c | c.name)").
A better answer would be: this issue should be raised with the OMG to
clarify the resolution of implicit source variables (if it isn't already on
the RTF's issues list). If you raise a bug on EMFT OCL, I'll see what can
be done in OMG.
Cheers,
Christian
Radek Dvorak wrote:
> Hi,
>
> The current EMFT OCL implementation (R1_0_maintenance branch only)
> excludes 'explicitly defined iterator variables' as a source of a
> property. It is done by design, as a result of the fix
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=151234
> While reading OCL 2.0 spec, I found myself in doubt, whether the spec
> clearly states this.
>
> There is section '7.8 Resolving properties', which describes how implicit
> iterator properties are handled.
> On the other hand, the section '9.3 Concrete Syntax' contains
> AttributeCallExpCS and
> Disambiguating rules:
> [A, B] 'simpleName' is name of an Attribute of the type of source or
> [if
> source is empty the name of an attribute of 'self'
> or any of the iterator variables in (nested) scope.
>
> So, it looks to me, that the resolution rule 'the most-inner-scope first'
> should be used also if an iterator variable is not implicit.
>
> To be accurate, the OCL expression bellow illustrates this topic.
>
> context ecore::EPackage
> eClassifiers->collect(classifier | name)
>
> Should the result collect the package name or EClassifiers names?
>
> Regards,
> /Radek
|
|
|
| Re: [OCL] Resolving properties, ambiguities [message #593719 is a reply to message #56648] |
Wed, 04 October 2006 23:07 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Thanks, for the answer.
As for the precedence problem, there is another section (though in that
non-trustable area ;))
'9.1 Structure of the Concrete Syntax/Disambiguating rules', which mentions
the precedence in my opinion.
Right, it's just an example, but '7.8 Resolv...' is nothing more.
Actually, that is why I have raised this question at all, as in this rule it
is stated 'all iterator variables'.
I even see these two cases as not mutally exclusive, but I did not have the
knowledge that I should not use
chapter 9 ;)
I can see it's really an issue for OMG. Not easy to use such specifications
:(
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:eg17ri$ef3$1@utils.eclipse.org...
>
> Hi, Radek,
>
> I would tend to follow (and actually did, as you indicated) the guidance
> of
> the discussion in chapter 7 about resolving the source of implicit feature
> calls. There are two problems with section 9.3:
>
> - none of the Concrete Syntax (chapter 9) has been updated to match
> the changes in the Abstract Syntax (chapter 8) in the latest draft
> of the spec, and is incorrect in some areas as a result (no null
> literal, still aligned with UML 1.4, etc.). The concrete syntax is
> now 3 years old by my reckoning
> - the disambiguating rule on the AttributeCallExpCS does not indicate
> whether the iterator variables take precedence over self or vice versa
> (remember that bug? :-)
>
> So, I would answer that your example should collect the same package name
> for every classifier. The convenience of syntactic shortcuts should be
> exploited to the fullest ("eClassifiers->collect(name)" or even
> "eClassifiers.name") or not at all ("eClassifiers->collect(c | c.name)").
>
> A better answer would be: this issue should be raised with the OMG to
> clarify the resolution of implicit source variables (if it isn't already
> on
> the RTF's issues list). If you raise a bug on EMFT OCL, I'll see what can
> be done in OMG.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi,
>>
>> The current EMFT OCL implementation (R1_0_maintenance branch only)
>> excludes 'explicitly defined iterator variables' as a source of a
>> property. It is done by design, as a result of the fix
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=151234
>> While reading OCL 2.0 spec, I found myself in doubt, whether the spec
>> clearly states this.
>>
>> There is section '7.8 Resolving properties', which describes how implicit
>> iterator properties are handled.
>> On the other hand, the section '9.3 Concrete Syntax' contains
>> AttributeCallExpCS and
>> Disambiguating rules:
>> [A, B] 'simpleName' is name of an Attribute of the type of source or
>> [if
>> source is empty the name of an attribute of 'self'
>> or any of the iterator variables in (nested) scope.
>>
>> So, it looks to me, that the resolution rule 'the most-inner-scope first'
>> should be used also if an iterator variable is not implicit.
>>
>> To be accurate, the OCL expression bellow illustrates this topic.
>>
>> context ecore::EPackage
>> eClassifiers->collect(classifier | name)
>>
>> Should the result collect the package name or EClassifiers names?
>>
>> Regards,
>> /Radek
>
|
|
|
Goto Forum:
Current Time: Thu Aug 29 15:13:05 GMT 2024
Powered by FUDForum. Page generated in 0.03959 seconds |
] 
Search
Help
Register
Login
Home
