TypedElement is no longer an ENamedElement

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 175446 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Feb 25, 2007 04:30 EDT | | Modified | May 27, 2011 02:42 EDT | | Reporter | Ed Willink |

Description

1.1M5

TypedElement does not extend ENamedElement, whereas TypedElement did.

This causes a conflict for QVT where FunctionParameter extends EParameter and Variable and so now has two distinct rather than identical 'name' features.

Please ensure that TypedElement gets its name feature from ENamedElement.

[eclipse-ocl-bot]

By Ed Willink on Mar 03, 2007 06:45

Until TypedElement is an ENamedElement, UMLReflectionImpl.getName() is broken since ENamedElement is the only ENamedElement it knows about.

[eclipse-ocl-bot]

By Ed Willink on Mar 17, 2007 11:57

This is causing me significant trouble so I thought I'd fix it.

It's horrible.

TypedElement obviously cannot inherit ENamedElement, without breaking the UML bindings, so the name part must move to a parameterised super type, so\ everything inheriting a TypedElement, which is rather a lot, must acquire\ an extra N parameter. TypedElement<N,C> therefore inherits N which provides the name.

The <EPackage, EClassifier, EOperation, EStructuralFeature,\ EEnumLiteral, EParameter, EObject, CallOperationAction, SendSignalAction, Constraint, EClass, EObject> list therefore needs an ENamedElement too.

I'm not sure whether C needs to be C. From experience, it does in some\ contexts, and does not in others. You cannot win. Complex Java generics\ makes for very flaky code.

I was a bit worried when I saw the massive parameter list. I don't think it's a sound design as this bug demonstrates. It would work in C++, where a traits class could publish the set of types, so that everything was just parameterised by a single ModelTraits from which e.g. ModelTraits::ClassType would provide as many distinct related type parameters as appropriate.

I suspect that there is a further problem with EStructuralFeature. This may need to be 3 parameters, the common abstract property type, and two more for the concrete reference/attribute types.

The multiple copies of e.g. TupleType with distinctly different inheritance are likely to make it very difficult to write accurate Ecore code.

I think this was an interesting experiment that must be abandoned.

[eclipse-ocl-bot]

By Christian Damus on Mar 24, 2007 00:40

I just did a quick experiment to follow through with target metamodel bindings for the Expressions package as was originally done for the Types package. That is, to specialize the Expressions metaclasses for Ecore/UML so that they can conform to ETypedElement/TypedElement in the same with that the Types metaclasses conform to EClassifier/Classifier in the org.eclipse.ocl.(ecore|uml) plug-ins.

Thus, we end up with the Ecore and UML bindings defining the complete OCL abstract syntax in terms of their target metamodels. Your initial problem of OCLExpression, Variable, etc. no longer being ETypedElements is thus resolved.

It seems to work (the JUnit tests pass). However, to make an extension to the OCL language (such as QVT) work for both Ecore and UML would require extending both of the Ecore- and UML-specific expression models, instead of just the one generic model as in M5. But, as far as I can tell, the only other way to get Ecore and UML support is to implement two distinct models with two disctinct parsers, anyway, and I don't know that that's any easier for anyone.

I'm not sure that Ecore properties will need any distinction between EReferences and EAttributes as far as OCL is concerned. Neither Core::Basic, EMOF, nor UML distinguishes different kinds of Property.

I don't know what you mean concerning TupleTypes. Are you referring to the definitions of the TupleType metaclass for the different target metamodels? Or multiple instances of the same TupleType metaclass?

[eclipse-ocl-bot]

By Ed Willink on Mar 24, 2007 03:07

#3: 'the JUnit tests pass'. Good. Please go forward as fast as possible preferably for M6 (unless you're going to backtrack). If any of your colleagues has massive Java generic experience, it might be a good idea to get their opinion on the wisdom of 10+ length parameter lists.

#2,#3: TupleType multiplicity. I was writing an instnaceof dispatch tree for an EClassifier (if Enum, else if DataType else Class ...) and added a TupleType for completeness; had considerable difficulty deciding which TupleType to choose from the Quick Fix, then investigated CollectionType and decided that I had got that wrong and hence had a null test just as if I'd written if AdaType. Garbage types are not reported by instanceof. Very user-unfriendly.

#2,#3:EReference. Just a suspicion, but after a further thought, you are defining abstract types and Java does not support new T() so maybe the concrete derivations are indeed unnecessary.

[eclipse-ocl-bot]

By Christian Damus on Mar 26, 2007 09:32

I don't know that there's anything inherently bad in longer or shorter lists of type parameters. If Java had a typedef or other aliasing mechanism, it would improve legibility of the code, but otherwise it's not that much different from parameterizing an object with values for 10 fields ...

Kenn, Ed: do you have any opinion on the subject of large generic signatures? One issue is that generic signatures cannot really evolve in an API-compatible way. You can't just add a type parameter, for example, because a binding for it would have to be added everywhere. OTOH, using Java reflection to handle the different target metamodels would result in an API that is very difficult to use. I don't really think that this is a concern, though, because if and when the OCL language should change to handle entirely new modeling constructs introduced by Ecore/UML, then API compatibility likely wouldn't be feasible anyway.

The only way to backtrack from the 1.1M5 design at this stage is to mark it as "experimental" and un-deprecate the 1.0/1.1M4 API.

Yes, the replication of type names is a little awkward, but JDT has mechanisms to help, such as type filters and an increasing degree of control over the relative ordering of completion suggestions. If your application is dealing with the Ecore binding in particular, then you can filter out the generic types. Otherwise, if your application is generic, then the Ecore and UML bindings won't be on your classpath, anyway.

[eclipse-ocl-bot]

By Christian Damus on Mar 27, 2007 16:57

Committed a fix to CVS, implementing Ecore and UML bindings for the OCL Expressions package, as described in coment #3.

This is published in the I200703271636 build, soon to become available on-line. A few incompatible API changes are described at http://wiki.eclipse.org/index.php/OCL_1.1_API_Changes.

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2007 13:54

Major problems with the build.

a) the feature reference to lpgjavaruntime is to a later build of an earlier version.

b) org.eclipse.ocl.utilities.TypedElement has no setName() method.

b) kills me.

When I restore the double inheritance of FunctionParameter to Variable as well as Eparamter, I get the following methods unimplemented in FunctionParameterImpl:

public OCLExpression<EClassifier> getInitExpression();\
public EParameter getRepresentedParameter();\
public void setInitExpression(OCLExpression<EClassifier> value);    public void setRepresentedParameter(EParameter value);\
public EClassifier getType();

maybe a consequence of the multiple inheritance join, maybe an EMF bug, not investigating while b) is outstanding.

Not sure how you're surviving this because the setName is in genVariableDeclaration.

[eclipse-ocl-bot]

By Christian Damus on Mar 28, 2007 14:28

a) Appears to be a bug in our build scripts. I'll have to look into that and spin another build.

Concerning b) :

org.eclipse.ocl.utilities.TypedElement has no setName() operation because the "name" and "type" properties were removed, these being defined instead by the metamodel-specific binding, now. The getName() and getType() operations implement read-only properties (as far as a client of the generic API is concerned) without actually defining properties, which I cannot do because EMF doesn't support property redefinition. The UMLReflection interface now has setName(TypedElement, String) and setType(TypedElement, C) methods as described in http://wiki.eclipse.org/index.php/OCL_1.1_API_Changes. This is consistent with the way reflection on the target metamodel is generally done by the parser.

genVariableDeclaration was updated to use the new UMLReflection methods. Have a look at the difference here:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl/plugins/org.eclipse.ocl/src/org/eclipse/ocl/internal/parser/OCLParser.java?root=Modeling_Project&r1=1.4&r2=1.5

The initExpression, representedParameter, etc. are modeled as regular EReferences. I don't see how they should ever be generated as empty methods. They aren't in org.eclipse.ocl.ecore ...

[eclipse-ocl-bot]

By Christian Damus on Mar 28, 2007 15:15

Note that, when working with a particular binding (e.g., Ecore) of the expressions package, these setter methods are inherited from ETypedElement, anyway. So org.eclipse.ocl.ecore.Variable has a setName(String) and setEType(EClassifier) operations. The problem on the UML side is that OCL seems to have forgotten that the root of the UML type system is Type, not Classifier. So, UML TypedElement has setType(Type), not setType(Classifier).

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2007 15:31

re: setName -- ok I'll move all the code across again. (It would be good to know if you're going to take the extensible parser on-board so that I can stop chasing, or whether I should organise it more permanently as a rival code base.)\ But I don't see why I can't do aVariable.setName("xx"). This seems to be a catastrophic drift from standard EMF behaviour that I'm sure is going to ripple and ripple. Ditto and perhaps more importantly setType(); names might be stable, types may be deduced later, and in the absence of paramterised constructors everything gets set late anyway.

In terms of my EQVT model, it's beginning to look promising. I had the wrong Variable. I just have to delete all the generic parameters that I added so laboriously two weeks ago. At least deleting is much easier. The end result is that if I had gone straight from M5 to M6 I might have not needed to change much.

re: the 5 methods. It's a genmodel bug, which Ed may not be ready for yet. genmodel generates the method setInitExpression(OCLExpression) in derived classes that have bound C to EClassifier, so Java reports that setInitExpression(OCLExpression is missing and gets prolifically upset about C.

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2007 15:43

OCLFactory doesn't work for Ecore.

I'm using the Ecore Variable type, so I expect to be able to assign\ the return from OCLFactory.createVariable() to it. I can't because the\ generic factory returns the generic rather than the specialised Variable.

Needs an EcoreOCLFactory with the specialised interface types.

[eclipse-ocl-bot]

By Christian Damus on Mar 28, 2007 15:54

(in response to comment #10)

Ah, yes. That seems to be related to bug 167935 that I raised when I began this OCL work. I do a lot of search-and-replace every time I generate :-(

Sorry that I haven't replied yet on the extensible parser bug. That was just too late in the release cycle to get the necessary inspection and legal clearance from the Foundation. I want to review it for the next release, as extensibility of the parser would be a good thing. So, by all means, continue to maintain it! I still have some grammar bugs to fix in this release, though.

About the setType() ... my main concern was for the clash between setName(Classifier) and setName(Type) in the UML binding. I suppose it shouldn't really be a problem, though. I can add the setter operations to the model without actually defining EReferences, if it's important to do that generically.

Thanks a lot for picking these changes up so quickly and reporting on how it's working for you. That is much appreciated, as M6 is this Friday!

(in response to comment #11)

The OCLFactory is for the parser's benefit. If you're working with the Ecore binding, it's easier to use the org.eclipse.ocl.ecore.EcoreFactory to create Variables and such. Otherwise, you would have to cast. At one point, I tried to make the EcoreFactory implement OCLFactory and narrow the return types, but that didn't work. The JDT seemed to produce bytecodes that worked, but the build didn't (it resulted in a raft of AbstractMethodErrors).

[eclipse-ocl-bot]

By Christian Damus on Mar 28, 2007 16:47

OK, I have restored the setName() and setType() operations on the org.eclipse.ocl.utilities.TypedElement interface. It wasn't the problem I thought it would be.

The OCL tests pass, as do the GMF tests for OCL validation (org.eclipse.gmf.validate plug-in).

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2007 16:48

There is no specialisation of ExpressionsSwitch, so my unparser that uses switch cases goes completely astray needing to implement all the methods with spurious template signatures that then get cast away.

EcoreFactory is a really unfriendly name, since it is the same as the standard Ecore factory.

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2007 17:13

setType and setName are a great help; I'm suddenly down to 20 errors from 200.

ETypedElementImpl is the join of TypedElement and ETypedElement, so it should provide the implementations of get/setType in terms of get/setEType.

(Retract comment on ExpressionsSwitch for now - looks like at least partly my fault).

[eclipse-ocl-bot]

By Christian Damus on Mar 28, 2007 17:25

No problem.

ETypedElementImpl is defined by EMF; I can't change that. Do you mean the OCLExpressionImpl, VariableImpl, TupleLiteralPartImpl, and CollectionLiteralPartImpl in the org.eclipse.ocl.ecore plug-in that implement the TypedElement interface? These already do implement setType by delegation to setEType. Perhaps you didn't update the org.eclipse.ocl.ecore plug-in ...

[eclipse-ocl-bot]

By Ed Willink on Mar 29, 2007 03:11

I misread the massive Type Hierarchy. My class was indeed the join so I added the set/getType.

A genuine problem.

org.eclipse.ocl.ecore.impl.VariableImpl.getInitExpression() returns\ org.eclipse.ocl.expressions.OCLExpression rather than\ org.eclipse.ocl.ecore.OCLExpression.

I've hit this before when I tried using a derived layer of specialised classes which at least had distinct names throughout.

Fixing the getXXX return type is easy, but then you have to change the xxx field type, which is easy, but then you have to change the setXXX type, which seems easy with different names, but a bit nasty with the same names. Even when you can change the setXXX signature you run into trouble with ensuring that all providers have validated their down-casts. The difficulty is that the Ecore reader is tending to deal with the declared type of the XML element rather than the derived type that applies to the derived application class set.

I eventually gave up, deciding that EMF did not allow derived classes to narrow a property classifier. After all the EMF model says xxx may be an XXX therefore the EMF framework only ensures that setXXX is invoked with an XXX when a model is loaded.

I've never quite understood the EMF derived attribute but it didn't seem to solve the problem of a derived type constraint.

The EMF error handling may now be good enough to allow the derived setXXX to throw a CCE for an insufficiently narrow type. When I was doing this a couple of years ago, a CCE during a Sample Ecore Editor load was diagnosed by a single fatal and very obscure stack trace without source model context.

Even with a CCE in the setXXX method, you have the undesirable behaviour that user code only gets the compile-time type check while the derived type is preserved.

With the current design I think you must change the property type to put a CCE in the inherited setXXX method, and provide an additional setXXX method for the derived type that just invokes the type checking method.

[Given the size of org.eclipse.ocl.ecore, has this design unravelled? It's getting as big as the full non-generic implementation. Any new binding is going to be equally large. It's easier to write a MyOCL to/from EcoreOCL converter than to configure MyOCL as a generic OCL binding? - or at least it would be if a little attention was paid to the EMOF to Ecore conversions.]

[eclipse-ocl-bot]

By Christian Damus on Mar 29, 2007 09:02

Right, EMF does not support redefinition of properties, not for narrowing their types or for other constraints. But, that isn't the purpose of the org.eclipse.ocl.ecore package. Its purpose is to provide implementations of the generic interfaces that extend the Ecore metamodel, conforming to its various EClassifier, ETypedElement, etc. metatypes. I guess the way to use this package is to use its factory for creating objects, but otherwise to work in terms of the generic API.

I don't see why the size of a package is a concern. Every class in org.eclipse.ocl.ecore is already understood as easily as any in org.eclipse.ocl.expressions/types or org.eclipse.ocl.uml. The corresponding types all have the same meaning. Even adding up all of the expressions and types classes in the generic OCL model and its Ecore and UML bindings, you get fewer metaclasses than are in the UML metamodel :-) OTOH, one thing I would like to do for the next release is a generator for metamodel bindings, in which a developer needs only to specify the EClasses substituting for the generic type parameters of the Environment and an Ecore model of the binding is generated with all the right type arguments and generalizations. I could possibly even throw that in as an "example" plug-in if I can find time.

[eclipse-ocl-bot]

By Ed Willink on Mar 29, 2007 15:57

"that isn't the purpose of the org.eclipse.ocl.ecore package" but it is the effect because org.eclipse.ocl.ecore.OCLExpression is narrower than org.eclipse.ocl.expressions.OCLExpression.

Fundamentally you have come up with a design that would work very well in C++, where very loosely\ typedef org.eclipse.ocl.expressions.OCLExpression org.eclipse.ocl.ecore.OCLExpression;\ makes org.eclipse.ocl.ecore.OCLExpression the same type as org.eclipse.ocl.expressions.OCLExpression.\ The two can be used interchangeably. It can work even better in C++ since the group of type parameters\ could be typedefs of a Traits class.

However this is Java, and so you have a derived class that is not the same type and since it\ may have sibling classes is narrower than its base type. Therefore every occasion when an inherited\ method is invoked that of course returns a generic type, there is a problem because the generic type\ needs a cast. The use of oclFactory or equivalent does not make the casts completely safe; there is no\ prohibition on accidental creation of a Variable<EClassifier,EParameter> in loose code; discovery of the\ the problem awaits failure of the downcast. It would also be possible to accidentally mix UML and Ecore\ bindings to really daft undiagnosed effect. These accidents are particularly easy when the same type\ names are used at different levels. Programmers with limited Java type checking, as was required\ for EMF till recently, will get no diagnosis of missing parameter lists.

In addition to numerous getXXX methods in the OCL model this also applies to\ generic classes such as Environment. Thus EcoreEnvironment.getSelfVariable() returns\ a Variable<C,PM> rather than a Variable.

My premature comments about ExpressionsSwitch were resolved when I discovered\ EcoreSwitch, which very satisfactorily allows me to implement an Ecore specific\ dispatcher, but I get about 30 problems needing down casts because getXXX methods\ do not return the true types.

If I was following your design honestly, I would have a problem with ExpressionsSwitch,\ which should be able to dispatch according to the generic types, but a derivation\ using non-generic types hits the minor issue that ExpressionsSwitch lacks the 12 long\ generic parameter list, and so dispatches to accidentally rather than necessarily the same\ parameters in each method, and the more major issue that a derivation of ExpressionsSwitch\ for specific bindings must reimplement every case to change signatures.

The bottom line is that every class boundary between generic and specific types must introduce\ a casting layer to down cast all return values:\ e.g. Klass getKlass() { return (Klass)super.getKlass(); }\ and down cast all passed parameters:\ e.g. void setKlass(Klass k) { setKlass((Klass)k); } // ensure generic calls go specific\ void setKlass(Klass k) { super.setKlass(k); } // ensure specific calls exist

With the M6 design we have a generated meta-model that is awkward to maintain and edit, stresses EMF well beyond its supported functionality, which cannot quite support accurate property types for both input and output, and requires significant manual\ introduction of casting methods to avoid splattering spurious casts throughout code.

The straightforward M4 design worked well. Now it's broken. The extra overloads of the property type and the CCE checks are necessary to minimise the loss of functionality. To make the M6 design work, every single parameterisable argument and return type must be parametric type, so the parameter list probably needs to be 40-odd elements long, and in order to get any useful generic behaviour you probably cannot refer to just for Variable, it will need to be <V extends Variable<C,PM>> and in my experience this complexity can get very out of hand.

I'll plough on to see whether my code actually works. I expect it will, but there is a risk that Java is overstretched as well.

[eclipse-ocl-bot]

By Ed Willink on Mar 30, 2007 02:10

It's not as bad as 40 long. Perhaps 25. It's just all the classes that appear in field, argument or return contexts - most expression and type classes do not.

If you take the example of BasicEObject, all the new generic classes should be given a Basic prefix as an indication that the names should never appear in any field, argument or return context. The Basic types are a code sharing technique between multiple bindings that would ideally be invisible to specific bindings users.

The long parameter list fixes get/set. Basic avoids naming overload/confusion,\ particularly in xxxSwitch where the generic names get a _1 suffix.

Fixing xxxSwitch to support additional generic behaviour is slightly awkward because I need to insert MyBasicXxxSwitch above XxxSwitch but MyXxxSwitch below XxxSwitch in the inheritance. XxxSwitch does not easily have a supertype. A solution might be for the default return null of relevant XxxSwitch cases to return basicSwitchHelper.case... so that every case not handled by a derived MyXxxSwitch can be delegated to a MyBasicXXXSwitchHelper that inherits\ BasicXxxSwitchHelper with the full 40 long parameter list.

[eclipse-ocl-bot]

By Christian Damus on Mar 30, 2007 08:35

(in reply to comment #19)

Yes, Java generics are severly limited when compared with C++ or Eiffel, to name two successful generic languages.

Java generics always require casts; sometimes the compiler inserts them, sometimes the developer does. For the user of an API, perhaps generics remove some of the tedious and error-prone casting. Java never promised the same for the implementer of an API.

The OCLFactory is modeled after the EMF-generated factory interfaces, which define methods that I call "free radicals": their generic type parameters are used only by the return type, so there are no constraints on how the Java compiler will interpolate the generic substitutions. I like to follow EMF's lead where I can; things usually turn out right when I do. If accidental bad casting is a problem in OCL, then it will be the same problem in all generic EMF models.

I'm not worried about users mixing up their Ecore and their UML in the same OCL environment. The OCL (the class), OCLHelper, Environment, etc. APIs keep them straight by tying all of the generic type parameters together into a coherent binding when starting from one of the org.eclipse.ocl.ecore.OCL or org.eclipse.ocl.uml.OCL entry-points into the parser/interpreter API.

The primary user of this API is the client that parses, evaluates, and persists OCL constraints on Ecore and UML models. For such users, this API seems to be working well since M5 and it isn't changed for them in M6 except for the need to instantiate Ecore- or UML-specific Variable implementations when adding custom variables to the Environment, and even then only if these variables need to be persisted. Writing bindings for other metamodels is expected to be less straight-forward, as is extending the OCL language for QVT. I am hoping that I will be able to work on some tooling in the next release that eases this activity.

The 1.0/1.1M4 design didn't work well because it was tied to a single target metamodel: Ecore. The 1.1 design is the most practical approach I could come up with to remove this limitation. I could have written everything generically with Object as the signature, but I think using Java generics to add meaning to occurrences of Object helps my primary users.

(in reply to comment #20)

Every type variable in the OCL API corresponds to one of the modeling constructs required by the OCL metamodel that is defined by the target metamodel. All other constructs are defined by OCL, so I deliberately tried to avoid complexity by not parameterizing them. You're quite right that introducing <V extends Variable<C, PM>> will add unnecessary complexity! You should have seen the fun I had getting generic signatures of the Visitor/Visitable pair of interfaces that actually work ...

I certainly wouldn't want to rename the model types in the org.eclipse.ocl plug-in: these are the ones that users of the API will work with most, as the result of parsing constraints and maybe analysing them with Visitors etc. The only classes from the metamodel-specific bindings that I expect most users to deal with are the OCL and factory classes (the latter only for creating Variables, really). Maybe I can even shortcut that by adding a helper method to the OCL class that creates a variable of the appropriate implementation.

The ExpressionsSwitch and TypesSwitch in the generic layer work well for me, in the syntax completion support and elsewhere. I don't see why the switches in the binding packages should be needed.

I still see the generic API being what users will use, the bindings only providing the implementations of the generic API for compatibility with the target metamodel and for persistence.

[eclipse-ocl-bot]

By Ed Willink on Mar 30, 2007 10:42

I was about to say go for M6, if it suits modellers, the programmatic API can follow. Then I hit another problem.

But firstly wrt to #21 "I certainly wouldn't want to rename the model types in the org.eclipse.ocl plug-in: these are the ones that users of the API will work with most, as the result of parsing constraints and maybe analysing them with Visitors etc".

This was true at the start of M5 with the introduction of generics to the Types. I had to add <EClassifier,EParameter> throughout a lot of code. The \ introduction of generics to Expressions has made thinbgfs a lot simpler. I have deleted the <EClassifier,EParameter> throughout since I almost see a model that comprises just org.eclipse.ocl.ecore.OCLExpression and org.eclipse.ocl.ecore.Variable etc; just as I did on M4 - package path obviously changed but otherwise the same. The problem is that org.eclipse.ocl.ecore.Variable.initExpression is not an org.eclipse.ocl.ecore.OCLExpression which is wrong. Ok I can cast but that is extremely inelegant, contrary to the EMF way, and wasn't necessary on M4. In the case of non-unit multiplicity I cannot cast, because EList is not castable to List.

New problem:\

I got my code successfully parsing and serialising, but then it crashed during deserialisation.

org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.eSet(int, java.lang.Object) line: 137 \ org.eclipse.ocl.ecore.impl.PropertyCallExpImpl(org.eclipse.emf.ecore.impl.BasicEObjectImpl).eSet(org.eclipse.emf.ecore.EStructuralFeature, java.lang.Object) line: 1061 \ org.eclipse.emf.ecore.xmi.impl.XMIHelperImpl(org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl).setValue(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EStructuralFeature, java.lang.Object, int) line: 1118 \ org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler(org.eclipse.emf.ecore.xmi.impl.XMLHandler).setFeatureValue(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EStructuralFeature, java.lang.Object, int) line: 2501 \ org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler(org.eclipse.emf.ecore.xmi.impl.XMLHandler).setFeatureValue(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EStructuralFeature, java.lang.Object) line: 2491 \ org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler(org.eclipse.emf.ecore.xmi.impl.XMLHandler).createObjectFromFeatureType(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EStructuralFeature) line: 2006 \ org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler(org.eclipse.emf.ecore.xmi.impl.XMLHandler).createObject(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EStructuralFeature) line: 1874 \ org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler(org.eclipse.emf.ecore.xmi.impl.XMIHandler).createObject(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EStructuralFeature) line: 131

The ultimate crash is that an EObjectImpl got created for a referredProperty,\ seemingly because the feature defined for org.eclipse.ocl.expressions.PropertyCallExp.referredProperty is a P for which the eReferenceType is an EObject, not an EAttribute. It would appear that the specialised feature has not been used and so the generic rather than specific type is created during deserialisation.

The offending XML snippet is:

        <source xsi:type="ocl.ecore:PropertyCallExp" xmi:id="ast60">\
          <eType xsi:type="ecore:EClass" href="umlMM.emof#umlMM.Package"/>\
          <source xsi:type="ocl.ecore:VariableExp" xmi:id="ast75" name="c">\
            <eType xsi:type="ecore:EClass" href="umlMM.emof#umlMM.Class"/>\
            <referredVariable href="ocl:///oclenv.ecore#/1"/>\
          </source>\
          <referredProperty href="umlMM.emof#umlMM.Classifier.namespace"/>\
        </source>

so the outer source correctly defines the specific PropertyCallExp, which means that the referredProperty should not need an xsi:type. Clearly it does with the M5 EMF/XMI reader.

[eclipse-ocl-bot]

By Christian Damus on Mar 30, 2007 11:01

Yep, I hit that one too: bug 179339, which Ed Merks has already fixed (though not in time for EMF M6, unfortunately).

I'm glad that, apart from this proxy problem (just take the next EMF M7 I-build to get the fix), it's working for you!

Yes, the default code generation for multiplicity-many features produces EList instead of EList<? extends T>. However, this is unavoidable, as it must be possible to add Ts to the list. Conversely, EList<? super T> doesn't work because it must be possible to get Ts from the list.

[eclipse-ocl-bot]

By Ed Willink on Mar 30, 2007 12:30

The List problems is just the same problem again. The derived layer does not consistently get derived types. Whenever a generic type appears there is a coding stupidity to sort it out. The problems cannot be resolved until

Variable extends BasicVariable<EClassifier, EParameter, OCLExpression>\ OCLExpression extends BasicOCLExpression\ LetExp extends BasicLetExp<EClassifier, EParameter, Variable, OCLExpression>\ CollectionLiteralExp extends BasicCollectionLiteralExp <EClassifier, CollectionLiteralPart>\ OperationCallExp extends BasicOperationCallExp<EClassifier, EParameter, OCLExpression, EOperation>\ TupleType extends BasicTupleType<EClassifier, EOperation, EStructuralFeature>

etc. (I don't think the V extends BasicVariable will be necessary or helpful).

If Ed has fixed the deserialisation, that's fantastic. I thought it was fundamental, and not solved by my suggestions. Will it be EMF M6a? You can't have an OCL M6 that depends on an Ibuild.

Just introduce the fully parameterised Basic... (which modellers should never see because they should always be working 100% Ecore or 100% UML or 100% oblivious) and we're there.

NB. The EcoreSwitch method names also strongly argue for Basic...

[eclipse-ocl-bot]

By Christian Damus on Mar 30, 2007 13:10

OCL M6 will be built with EMF M6. The class-cast exception only happens on proxies that can't be resolved, so it's a marginal scenario that's not worth waiting for.

Why should modellers work with the derived Ecore or UML types exclusively? I hope that most applications using MDT OCL will want to support any metamodel for which a binding is available. This means using the generic API, which names I don't want to load up with a "Basic" prefix.

[eclipse-ocl-bot]

By Ed Willink on Mar 30, 2007 13:59

Never having used the UML2 project facilities in earnest I may have missed the point.

I wrote 100% Ecore or 100% UML or 100% oblivious.

The latter case for expecting to be a neutral model. As a modeller I would expect to use the name 'Variable' not 'Variable<C,PM>', and would expect to be referring to a well defined class, of which Ecore and UML are currently the only variants. 'Variable<C,PM>' is not a well defined since C has no features. Again as a modeller I would expect to be OMG compliant and so would expect to use the UML bindings, unless I had explicitly requested the Ecore bindings because I intended to generate an Ecore tool. With UML and Ecore having name compatible models, I would expect the UML/Ecore choice to be a simple combo-box or equivalent in the GUI. None of these perspectives require the modeller to ever see the generic/basic classes.

[eclipse-ocl-bot]

By Christian Damus on Mar 30, 2007 18:28

The 1.1 M6 build now implements metamodel-specific bindings for the OCL Expressions package as well as Types, so that now the constituent parts of an OCL expression conform to the target metamodel's "typed element" metaclass.

[eclipse-ocl-bot]

By Nick Boldt on Jan 28, 2008 16:37

Move to verified as per bug 206558.

[eclipse-ocl-bot]

By Nick Boldt on Jan 28, 2008 16:41

Move to verified as per bug 206558.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:40

Closing after over a year in verified state.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:42

Closing after over a year in verified state.