Community
Participate
Working Groups
In the EcoreEnvironment( Registry, Resource) contructor, typeResolver would be better created via a factory method: protected EcoreEnvironment(EPackage.Registry reg, Resource resource) { this(reg); typeResolver = createTypeResolver(resource); } the factoryMethod: protected TypeResolver<EClassifier, EOperation, EStructuralFeature> createTypeResolver(Resource resource) { return new TypeResolverImpl(this, resource); }
Created attachment 83954 [details] Patch for resolve the bug in Ecore & UML implementations
[EcoreEnvironment offers three constructors. Only two of these allow the TypeResolverImpl to be overridden in derived environments. Overriding is essential to support an alternate policy for resolution of orphan types as required by QVT.] AbstractTypeResolverImpl(env) redirects to AbstractTypeResolverImpl(env, null) so it would make sense if createTypeResolver() was changed to createTypeResolver(resource). Suggest deprecated rewrite of existing method to redirect protected TypeResolver<...> createTypeResolver() { return createTypeResolver(null); } and new overrideable protected TypeResolver<...> createTypeResolver(Resource resource) { return new TypeResolverImpl(this, resource); } so that derivations need only override the new method to affect all 3 construction paths.
Committed Adolfo's patch with the changes suggested by Ed. Additionally removed the lazy initialization of the type resolver in the accessor because it is now always created on construction. Existing clients that overrode the original createTypeResolver() method should see no change in behaviour, except that it is created now on construction, instead of lazily.
Ta. Just a suggestion: It looks as if the typeResolver member and all bar the createTypeResolver implementation could be promoted to AbstractEnvironment.
Yes, perhaps the TypeResolver should be promoted to AbstractEnvironment, but since the creation of the resolver depends on a specific implementation, an abstract method should be defined in the AbstractEnvironment, so UML & Ecore implementation should override it. P.D: Why am i "assigned to" in the bug ? -> lol
Adolfo, you are the assignee because that is part of the process in the Modeling project (and, I think, Eclipse generally) for attributing contributions to non-committers. One of these days, people like Ed will be seeing themselves assigned bugs that were long since committed and resolved, that they contributed. I can't create a new abstract method in the AbstractEnvironment class because that is an incompatible API change, and I wouldn't be able to provide a useful implementation.
Fixed in the MDT OCL 1.2.0 I200712061132 build.
Move to verified as per bug 206558.
Closing after over a year in verified state.
