Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » EObject methods will not be available after Helios M4 milestone.
EObject methods will not be available after Helios M4 milestone. [message #503364] Sat, 12 December 2009 11:58 Go to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi

An accidental feature of EMF up until 2.6M4 was that EModelElement
extended EObject, with the result that EObject methods such as
eContainer(), eContents(), eGet() could be used in OCL expressions on
models that extended EModelElement. If as recommended by a number of
newsgroup postings, the IMPLICIT_ROOT_CLASS option was set to EObject,
the EObject methods could be used for any models.

EMF is discontinuing this inheritance in 2.6M4
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469). This breaks
backward compatibility, but eliminates an unwanted incompatibility with
the OCL specification. EObject methods will not be available without
some new approach.

My current favoured approach is to support e.g.

self.oclAsType(ecore::EObject).eContainer()

so that the only deviation from the specification is a built-in
visibility of ecore::EObject and the successful cast to a Class not in
the meta-model.

Now that OCL 2.1 has made it clear that MOF reflection is not supported
for models, I am considering submitting an OMG issue that adds the
reflective methods:

OclAny::oclContainer()
OclAny::oclContents()
OclAny::oclGet()
OclAny::oclSet()

etc. These methods could be compatible with other non-Ecore OCL
implementations.

Comments on the above proposals are welcome.

Regards

Ed Willink
Re: EObject methods will not be available after Helios M4 milestone. [message #503568 is a reply to message #503364] Mon, 14 December 2009 17:43 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dvorak.radek.gmail.com

Hi Ed,

I would like to discourage from adding reflection to OclAny.
What kind of container(), contents(), get() do we have for
example for primitive types?

The QVT spec adopts the MOF Element concept, at least there has been
an attempt ;), so it defines a subset of its reflection capabilities
+ some additions.
As an extension to OCL, QVT would now receive a duplicate functionality via
OclAny.

If OCL 2.1 needs to address reflection and an issue has to be submitted,
why
not to unify on something reasonable for all possible languages built
on the top of OCL?

To my observations, if IMPLICIT_ROOT_CLASS is explicitly set in
Environments (as EObject) by OCL clients, they sort of get what they had
in the past.

Regards,
/Radek


On Sat, 12 Dec 2009 12:58:17 +0100, Ed Willink <ed@willink.me.uk> wrote:

> Hi
>
> An accidental feature of EMF up until 2.6M4 was that EModelElement
> extended EObject, with the result that EObject methods such as
> eContainer(), eContents(), eGet() could be used in OCL expressions on
> models that extended EModelElement. If as recommended by a number of
> newsgroup postings, the IMPLICIT_ROOT_CLASS option was set to EObject,
> the EObject methods could be used for any models.
>
> EMF is discontinuing this inheritance in 2.6M4
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469). This breaks
> backward compatibility, but eliminates an unwanted incompatibility with
> the OCL specification. EObject methods will not be available without
> some new approach.
>
> My current favoured approach is to support e.g.
>
> self.oclAsType(ecore::EObject).eContainer()
>
> so that the only deviation from the specification is a built-in
> visibility of ecore::EObject and the successful cast to a Class not in
> the meta-model.
>
> Now that OCL 2.1 has made it clear that MOF reflection is not supported
> for models, I am considering submitting an OMG issue that adds the
> reflective methods:
>
> OclAny::oclContainer()
> OclAny::oclContents()
> OclAny::oclGet()
> OclAny::oclSet()
>
> etc. These methods could be compatible with other non-Ecore OCL
> implementations.
>
> Comments on the above proposals are welcome.
>
> Regards
>
> Ed Willink
>
>
>
Re: EObject methods will not be available after Helios M4 milestone. [message #504642 is a reply to message #503568] Mon, 21 December 2009 21:05 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi Radek

My ideas have progressed a little, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=283052#c6 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259031#c12

For MDT/OCL there are an embarrassing number of bugs related to the (lack of a) run-time type system and the second-class status of
oclstdlib as a model. I would like to address these by creating an extensible modelled run-time type system, so that the oclstdlib
model defines behaviour rather than a large number local if inaccurate clauses. Conformance to OclAny will then be defined by a
particular oclstdlib meta-model instance rather than MDT/OCL Java code. QVTo should then be able to provide an alternate or extended
oclstdlib meta-model instance.

For OMG OCL, there is a major problem that the type system of the library is never explicitly defined.
In particular the incompatibility of the Standard Library's concept of 'conformsTo' and the UML concept of generalisation was
identified first by Christian Damus in http://www.omg.org/issues/ocl2-rtf#Issue12795 and in greater depth by me in a not yet visible
submission.

The problem is that OCL at run-time is not the same as UML and pretending that it is has led to this problem. It is the missing
oclstdlib meta-model that defines the 'conformsTo' relationship allowing YourClass to conformTo OclAny even though OclAny is not a
general of YourClass. Similarly it is the oclstdlib meta-model that provides feature polymorphism between a meta-model (e.g.
YourCollection::size(), a constraint (context YourCollection def: size() Integer ...) or a built-in (Collection::size()). And it
will be the oclstdlib meta-model specification that removes the UML specification variation point on whether method overriding
occurs or not.

If the standard library is defined using an OCL run-time library meta-model, a very attractive number of problems appear to vanish.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259031#c12 indicates my intention to work on this a a ReflectiveLIbrary branch to see
how it works out. I am hoping that UML and Ecore bindings will be an irrelevant choice from the OCL programmers point of view; the
parameterisation of OCLExpressionCS<C> might be obsolete. The UML and Ecore bindings choice will affect only toolsmiths who through
Environment<?,?,?,?,?,?,?,?,?,?,?,?> can select the meta-model representation they prefer.

This is happening in a branch

a) to find out what is possible
b) then to establish a maximum/acceptable compatibility between the old and new code

The ReflectiveLibrary branch is my private work area, feel free to examine it, but do not expect it always to be coherent; it is not
a release. Do not attempt to build against it. Some APIs will be broken to assess their impact, and most will probably be restored
as part of the acceptable compatibility phase.

I am acutely aware that there is limited time before M6, so something radically different needs to be highly compatible.

Implementing IMPLICIT_ROOT_CLASS as you suggest may well be a necessary compatibility.

Regards

Ed Willink


radek dvorak wrote:
> Hi Ed,
>
> I would like to discourage from adding reflection to OclAny.
> What kind of container(), contents(), get() do we have for
> example for primitive types?
>
> The QVT spec adopts the MOF Element concept, at least there has been
> an attempt ;), so it defines a subset of its reflection capabilities
> + some additions.
> As an extension to OCL, QVT would now receive a duplicate functionality via
> OclAny.
>
> If OCL 2.1 needs to address reflection and an issue has to be submitted,
> why
> not to unify on something reasonable for all possible languages built
> on the top of OCL?
>
> To my observations, if IMPLICIT_ROOT_CLASS is explicitly set in
> Environments (as EObject) by OCL clients, they sort of get what they had
> in the past.
>
> Regards,
> /Radek
>
>
> On Sat, 12 Dec 2009 12:58:17 +0100, Ed Willink <ed@willink.me.uk> wrote:
>
>> Hi
>>
>> An accidental feature of EMF up until 2.6M4 was that EModelElement
>> extended EObject, with the result that EObject methods such as
>> eContainer(), eContents(), eGet() could be used in OCL expressions on
>> models that extended EModelElement. If as recommended by a number of
>> newsgroup postings, the IMPLICIT_ROOT_CLASS option was set to EObject,
>> the EObject methods could be used for any models.
>>
>> EMF is discontinuing this inheritance in 2.6M4
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469). This breaks
>> backward compatibility, but eliminates an unwanted incompatibility
>> with the OCL specification. EObject methods will not be available
>> without some new approach.
>>
>> My current favoured approach is to support e.g.
>>
>> self.oclAsType(ecore::EObject).eContainer()
>>
>> so that the only deviation from the specification is a built-in
>> visibility of ecore::EObject and the successful cast to a Class not in
>> the meta-model.
>>
>> Now that OCL 2.1 has made it clear that MOF reflection is not
>> supported for models, I am considering submitting an OMG issue that
>> adds the reflective methods:
>>
>> OclAny::oclContainer()
>> OclAny::oclContents()
>> OclAny::oclGet()
>> OclAny::oclSet()
>>
>> etc. These methods could be compatible with other non-Ecore OCL
>> implementations.
>>
>> Comments on the above proposals are welcome.
>>
>> Regards
>>
>> Ed Willink
>>
>>
Previous Topic:How to convert Self.description to xsd::DOMElement
Next Topic:EMF with OCL
Goto Forum:
  


Current Time: Mon Dec 22 15:55:31 GMT 2014

Powered by FUDForum. Page generated in 0.15269 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software