Bug 259031

Comment 1 Adolfo Sanchez-Barbudo Herrera 2008-12-24 07:11:07 EST

Well, I suppose that we will have to wait until OMG's OCL 2.1 specification comes up.

On the other hand, this feature will definetely appear in the further MDT-OCL 2.0.0. However, since including this shouldn't break any API, it could be included for galileo release. What do you think ?. 

Comment 2 Nicolas Rouquette 2009-01-12 00:16:40 EST

I'm all for including/prototyping this functionality in the galileo release.

Comment 3 Christian Damus 2009-01-12 08:13:18 EST

(In reply to comment #1)
> 
> On the other hand, this feature will definetely appear in the further MDT-OCL
> 2.0.0. However, since including this shouldn't break any API, it could be
> included for galileo release. What do you think ?. 

The point that most concerns me about doing this in the Galileo release is compatibility with the existing implementation of the oclIsKindOf(OclType) operation and its cohorts.  The problem is, that we would need to be able to do something like this:

  context Classifier
  inv valid_generalizations:
     self.general->forAll(g | self.oclIsKindOf(g.oclType()))

which implies that the result type of the oclType() operation should be OclType (which, in the MDT implementation, actually means an instance of TypeType that is a subtype of OclType).  This further extends two existing problems:  MDT's mis-implementation of the Ocltype construct, and the very existence of that poor construct which OCL 2.1 eliminates.

Makes me loath to implement this in the current release ... Comments? Concerns?

Comment 4 Nicolas Rouquette 2009-01-27 01:27:05 EST

It doesn't make sense to me to waste energy on implementing a new feature on an old design that will have to change anyway as soon at the OCL 2.1 or 2.2 spec is out of the door. 

There is still plenty we can do with the current Eclipse MDT OCL.

If the new OCL 2.1 or 2.2 spec can be finished within a reasonable time frame, 
then there is a practical advantage on suspending work on this bug until then.
As you pointed out, the new spec will make obsolete the mis-implementation of the OclType construct.

Comment 5 Ed Willink 2009-07-01 07:52:22 EDT

Sadly we still have to fix bugs.

MDT-OCL 2.0.0 should support a user choice of OCL 2.0 or 2.1/2.2. When 2.0 is selected MDT-OCL should implement OCL 2.0 as accurately as is practical.

Comment 6 Ed Willink 2009-09-13 02:34:52 EDT

Created attachment 147054 [details]
Interim implementation of oclType

The attached implements OclAny.oclType() returning OclType (for OCL 2.0 OclAny).

Migration to an OclAny or Classifier return is different issue.

I'm not comfortable with having to fix an argument type lookup bug, and a UML evaluation type usage bug to make this work. I'm not happy that oclstdlib.uml requires oclType to be entered in everty type; there is no OclAny inheritance. I'm not happy that oclstlib.ecore doesn't seem to exhibit similar behaviour.

Note that OclInvalid does not implement oclType so that the invocation returns invalid not OclInvalid.

I think that we should significantly revisit this code when we try to make Collection inherit OclAny. EvaluationVisitorImpl.visitOperationCallExp is impossibly large.

Comment 7 Adolfo Sanchez-Barbudo Herrera 2009-09-21 06:52:39 EDT

Hi Ed,

I was wondering why is the reason of the interim implementation, just adding the operation ?. I was expecting the removal of TypeType, the stdlib's oclType and such...

Will my concerns be dealt in a different bug? In a further patch ? 

Cheers,
Adolfo.

Comment 8 Alexander Igdalov 2009-10-06 03:27:34 EDT

(In reply to comment #6)
> Created an attachment (id=147054) [details]
> Interim implementation of oclType
> 
> The attached implements OclAny.oclType() returning OclType (for OCL 2.0
> OclAny).
> 

Ed, this implementation returns the declared type but not the actual one.
IOW, the case below fails:

let s : OclAny = 'b' in 'a'.oclIsTypeOf(s.oclType())

Although the specification doesn't explicitly say whether the returned type must be actual or declared, it is probably implied that it is actual. Otherwise, oclType() is worthless.

Comment 9 Ed Willink 2009-10-06 15:42:09 EDT

Oh dear.

(It is of some use in creating a Type expression.)

I'm overloaded with language issues at present.

Would anyone like to take this one off my hands?

Comment 10 Adolfo Sanchez-Barbudo Herrera 2009-10-07 13:21:51 EDT

(In reply to comment #9)
> Oh dear.
> 
> (It is of some use in creating a Type expression.)
> 
> I'm overloaded with language issues at present.
> 
> Would anyone like to take this one off my hands?

I would like ;). I'm not able to work on this right now, though. 

I assign myself, and I'll announce when I start with it (after LPGv2 migration).

Cheers,
Adolfo.

Comment 11 Ed Willink 2009-12-05 08:56:37 EST

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=283052#c6 for a discussion on why oclType() must return a true Classifier that is not a org.eclipse.uml.uml2.Classifier and why we need to implement a true MOF model.

Comment 12 Ed Willink 2009-12-13 13:05:29 EST

Consideration of reflection points out that many current problems all stem from the lack of a run-time type system. X conformsTo Y is hand crafted and not always consistent. Find X::y() is differentl hand crafted with uncertainties about whether y() is built-in, from the met-amodel, or from a def-constraint. OMG issue 12854 raises the problem of how to serialize references to def-constraints as operations. My comments in Issue 14591 suggest that a meta-model merge is required. The status of built-in operations is particularly uncomfortable when is comes to making stdlib a regular model with two different bindings. The existing EMF-based reflection has been undermined by the EModelElement inheritance change.

These problems are all soluble or at least significantly mitigated by creating a merged meta-model.

All types are 'instances' of OclType.

The OclType.conforms (rather than superClasses) relationship models type conformance.

The OclType.operations : OclOperation models operations with three different flavours for a) built-in library operation, b) reference to meta-model operation, c) reference to def-constraint

The OclType.properties : OclProperty models properties with three different flavours for a) built-in library property, b) reference to meta-model property, c) reference to def-constraint

OclPackage, OclType, OclOperation, OclProperty, OclParameter should form a very lightweight, potentially demand-created, MOF-like model that provides the required OCL behaviours. Therefore OclPackage, OclType, OclOperation, OclProperty, OclParameter is a new EMF model of which the standard library is a potentially binding-independent instance.

For instance, invocation of an operation will involve locating the OclOperation appropriate to the invocation context, and invoking it. The three different flavours of operation will be polymorphic within the one model, so the custom coding should vanish.

With a proper run-time library Ocl meta-model issues such as https://bugs.eclipse.org/bugs/show_bug.cgi?id=283052#c6 should all drop out.

Ironically the prime beneficiary of this will be QVTo where ability to extend the standard library is most important. However there is very little chance that QVTo will be able to adapt to this capability by M6, so we must create this new functionality with minimal damage to the existing API.

[Correction OCLType etc rather than OclType]

This may need to turn into an OMG issue. Currently references to standard library operations use cryptic Eclipse-specific URIs. There should be an OCL standard spelling, which requires an OMG standard model.

I'll be working on this in a ReflectiveLibrary branch.

Comment 13 Ed Willink 2011-02-01 01:45:30 EST

OclAny.oclType is defined as part of the pivot-based standard library model.

[It dynamically return the type of self as a UML-aligned pivot model Type, and so supports reflection and multi-level oclType(0..

It is declared to return OclSelf, the statically determinate type of self.]

Comment 14 Ed Willink 2011-05-27 06:41:19 EDT

Resolved for Indigo is 3.1.0 not 3.2.0.

Comment 15 Ed Willink 2012-05-29 13:23:55 EDT

Closing all bugs resolved in Indigo.