Community
Participate
Working Groups
When trying to implement QVT Stdlib predefined types, I face a problem with 'List', 'Dictionary' types which extend OCL CollectionType. As for conformance to CollectionType, it can be realized with the current implementation, even though there is no clear contract for it. A subtype of the CollectionType having its kind == collection is processed as a legal collection and it simply seems working fine. /* Of course, a clear contract for such extensions would be ideal */ The only issue seems to be resolution of generic types on collections, as the implementation resolves them in a kind of hardcoded way. This is pretty OK for the OCL stdlib itself, but makes difficulties for QVT StdLib::Dictionary type, which is also a parameterized type but coming with yet another parameter 'keyT' (a HashMap like key type). A general mechanism to resolve any generic types defined by a custom environment would help here.
Created attachment 62385 [details] Resolving genericTypes.patch
*** Bug 244144 has been marked as a duplicate of this bug. ***
Consider resolving https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673 to solve this one, specially, when a contribution has been provided ;) The taken approach for the TypeUtil class, could be identically applied for the OCLStandardLibraryUtil class. Cheers, Adolfo.
Hi, we've got a similar need for MTL. Now expecting the 1.3 release :).
(In reply to comment #3) It seems to be partly addressed by the concept introduced in https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673. However, I can still see couple of places in AbstractOCLAnalyzer, ValidationVisitor, which only call OCLStandardLibraryUtil.getResultTypeOf(...). I would assume to delegate TypeChecker.getResultType(Object, C, O) for non-oclstdlib operations. Another point is, why TypeChecker interface does not take into account operation arguments, when obtaining the operation result type. By extending that operation signature as written bellow, we could resolve generic parameters as well. C getResultType(Object problemObject, C source, O oper, List<OCLExpression<C>> actualArgs) If I have not missed anything ;), this way I should be able to support generic operations just by providing a custom TypeChecker implementation.
(In reply to comment #5) > (In reply to comment #3) > It seems to be partly addressed by the concept introduced in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673. > > However, I can still see couple of places in AbstractOCLAnalyzer, > ValidationVisitor, which only call OCLStandardLibraryUtil.getResultTypeOf(...). > I would assume to delegate TypeChecker.getResultType(Object, C, O) for > non-oclstdlib operations. Right, I think we need to bring the OCLStandardLibraryUtil.getResultTypeOf(...) method into the TypeChecker API in the same way as the TypeUtil methods. Then, these calls will be re-directed by the OCLStandardLibraryUtil to the TypeChecker. > Another point is, why TypeChecker interface does not take into account operation > arguments, when obtaining the operation result type. Because it only implements the (old) TypeUtil::getResultType(...) API, which didn't account for arguments because it didn't need to consider parameter types that weren't covariant with the owner type. However, that TypeUtil API wasn't used by the parser (probably because it didn't account for the actual arguments), so we should be able to get rid of it. > By extending that operation signature as written bellow, we could resolve > generic parameters as well. > > C getResultType(Object problemObject, C source, O oper, List<OCLExpression<C>> > actualArgs) Yep. > If I have not missed anything ;), this way I should be able to support generic > operations just by providing a custom TypeChecker implementation. Nope, you haven't missed anything. :-)
Created attachment 117149 [details] A proposed TypeChecker solution Attached a patch that deprecates the existing TypeChecker::getResultType(...) operation in favour of a variant that accepts a list of the arguments of the operation call, for resolution of generic type variables in the parameter list. I would rather delete the variant without the arguments than deprecate it, as it was new in this release. How does everybody on the cc: list feel about that? Radek and Alex, in particular, I would very much appreciate your review of this patch.
Created attachment 117185 [details] ValidationVisitor patch I have found one place in ValidationVisitor.visitOperationCallExp(..), which should resolve possible generics too. Currently, the user operation is not given a chance to do so. See the attached patch. If applied, my QVT scenarios work perfectly, Thanks!
I have noticed one thing, which actually does not affect the functionality correctness but is rather a performance topic. I can see a couple of redundant checks like bellow: .. if ((sourceType instanceof PredefinedType) && !env.getAdditionalOperations(sourceType).contains(oper)) { .. It might look innocent for OCL ;), but in the QVT world it implies lookup through imported modules, thus imposing a certain penalty on all PredefinedType operations processing (especially if performed repeatedly). 1) done in AbstractOCLAnalyzer 2) done in ValidationVisitor 3) repeated in AbstractTypeChecker.getResultType(..) - though, here I can pretty simply figure out if it is a QVT defined operation and avoid delegation to the OCL default impl. Could there be a faster, likely an OCL internal way of how to decide whether it is an additional operation?
(In reply to comment #8) > Created an attachment (id=117185) [details] > ValidationVisitor patch > > I have found one place in ValidationVisitor.visitOperationCallExp(..), which > should resolve possible generics too. Currently, the user operation is not > given a chance to do so. See the attached patch. > If applied, my QVT scenarios work perfectly, Thanks! Thanks for the additional patch, and for testing this! (In reply to comment #9) > I have noticed one thing, which actually does not affect the functionality > correctness but is rather a performance topic. > I can see a couple of redundant checks like bellow: > .. > if ((sourceType instanceof PredefinedType) > && !env.getAdditionalOperations(sourceType).contains(oper)) { Heh heh ... Yes, I noticed those, too, while I was working on this. I was thinking of adding a method to the TypeChecker: isStandardLibraryFeature(C owner, Object feature) to provide a single locus of implementation of this check. > It might look innocent for OCL ;), but in the QVT world it implies lookup > through imported modules, thus imposing a certain penalty on all PredefinedType > operations processing (especially if performed repeatedly). > > 1) done in AbstractOCLAnalyzer > 2) done in ValidationVisitor > 3) repeated in AbstractTypeChecker.getResultType(..) > - though, here I can pretty simply figure out if it is a QVT defined > operation and avoid delegation to the OCL default impl. > > Could there be a faster, likely an OCL internal way of how to decide whether it > is an additional operation? Well, as the type-checker is an object owned by the environment, it has an opportunity to cache results or be customized by the QVT environment with a suitably efficient algorithm. Would this help?
(In reply to comment #10) The operation isStandardLibraryFeature(C owner, Object feature) would be useful. Our check whether it's a QVT operation or not is not expensive and so we can avoid eventual calls to the original implementation.
Applied my patch (attachment #117149 [details]). Applied Radek's additional patch to ValidationVisitor(attachment #117185 [details]). Added "List<? extends TypedElement<C>> args" parameter to TypeChecker::getResultType(...). Added "boolean TypeChecker::isStandardLibraryFeature(C owner, Object feature)" operation along with corresponding TypeUtil static.
Fix available in HEAD: 1.3.0.I200811191813.
Closing after over a year in verified state.
