Community
Participate
Working Groups
Continuing the side track from Bug 428028 > (In reply to Ed Willink from comment #21) > That's fine, but implies that Adolfo's > > mapping A::map(): B; > > is not invalid as proposed, but treated as if it has an empty body. I'm fine > with that, just wanted to raise awareness. Unfortunately we have no CS to AS specification so we are rather left to guess. ---------------- 'abstract' has two options: not-abstract => can execute in any way. abstract => can only execute indirectly by inheritance or merging. 'blackbox' / body has three valid options and one invalid blackbox, with-body => two bodies - syntactically invalid blackbox, without-body => one body - ordinary blackbox mapping not-blackbox, with-body => one body - ordinary QVTo mapping not-blackbox, without-body => no bodies - ? No bodies could be - a syntax error - equivalent to empty body - a prohibition on execution The prohibition might be useful. For an abstract no-body, it could be a compile-time prohibition on merged derivation but a permission for inherited refinement. For a non-abstract no-body, it could be a compile-time/run-time prohibition on any invocation - a bit like a Java method implemented as throw UnsupportedOperationException. --- The spec is unclear, so we should make a sensible choice. In view of compatibility, I favour treating no-bodies as empty body and if someone wants a prohibition capability then it needs explicit new syntax.
Hi Ed, I think that my vision starts to align with yours. On the other haand, one is what the specification needs to say, another one what Eclipse QVTo wants to do. So IMO, specification should say that a non-abstract,non-blackbox, non-bodied mapping is a compile-time error. Of course, for compatibility purposes Eclipse QVTo could accept it as an empty-bodied mapping as you suggest. The reasoning I had written about this topic, which covers some other points not mentioned by you.... follows below ---- Hi Folks, Bug 428028 came from Bug 289982 resolution which apparently assumed that a mapping without a body, should be considered as a blackbox, as the specification states: "A mapping operation may be provided with its signature only or may additionally be provided with an imperative body definition. In the former case, where there is no body provided, the operation is said to be a black-box" I believe that the specification is wrong to this respect: If not having a mapping body means blackBox, why do we have a isBlackbox property (and a keyword) for mapping operations ?. The specification is obviously wrong, but it could be so in two different ways : a) either the isBlackbox is a derived property from other AS properties. Then the "blackbox" keyword is not needed (could be there/even required for readability) b) or having or not a mappingBody doesn't imply being or not being a blackbox operation. The the "blackbox" keyword is needed to explicitly declare the mapping as a blackbox. I endevour for b). I think that Ed endevour for a): isBlackbox is deducible from other AS properties, that is, isAbstract and body. This is still erroneous in the current specification, since we don't have an "isAbstract" property in the AS syntax for mapping operations. Even if we had an isAbstract property for mappings... why blackbox is deducible from the isAbstract/body=null and not the other way: isAbstract is deducible from the isBlackbox/body=null. An illustrative example: mapping A::map(): B; a) is this a black-box mapping because it's a non-abstract one without body ? b) is this an abstract mapping because it's a non-blacknox one without body ? Any deduction rule here is confusing and error prone. In this case the better alternative is thinking of: c) This is a non-abstract, non-blackbox mapping (hence a "normal" mapping) without a body =>Error, a "normal" mapping needs always a body. So from my point of view, the specification needs to be corrected in two important ways: a) Remove that claim that a non-bodied mappings are a black-box. b) MappingOperation needs an isAbstract property (and constraints to detect invalid combinations of isAbstract/isBlackbox/body=null values) From the point of view of the CS: If you want an abstract mapping use the "abstract" keyword which maps with an isAbstract property. If you want an blackbox mapping use the "blackbox" keyword which maps with an isBlackbox property. This specification direction prevents the problems detected by Bug 428028. The announced 3 problems in that bug, materialize with those "abstract" mappings which don't define a mapping body, which is certainly a valid situation in the direction above. Finally to complete the explanation, I'd like to recall your attention about what an "abstract" mapping mean. I'm giving my point of view: - What does "abstract mapping" mean in QVTo ? An operational mapping which needs to be extended by at least one mapping via: a) normal operation overloading mechanism. b) any of the mapping extension mechanism. "abstract mappings" are mandatory when the created object is an "abstract" element (there should be another mapping creating the concrete element) and they might (or not) contain a mapping body. Examples: abstract a::mapping1(): B; // A possible disjuncting mapping. abstract a::mapping2(): B { // initialization of some properties of an abstract class B } - Does it need to be modelled (AS) ? How ? I think so, otherwise how are transformations well-formed? We need to know which mappings are declared as abstract to check that they are properly being extended by another mapping in a potentially complex transformation hierarchy. This is modelled with a simple isAbstract property in OperationalMapping (maybe ImperativeOperation ?). - Does it need to be specified in a transformation file (CS) ? How? Yes of course, with the "abstract" keyword. If anything doesn't make sense, please, let me know. Another interesting point if this "specification" direction clashes with some current Eclipse QVTo transformation syntax to avoid incompatibilities. I guess that Sergey could give us a better insight here.
(In reply to Adolfo Sanchez-Barbudo Herrera from comment #1) > "abstract mappings" are mandatory when the created object is an > "abstract" element Not necessarily in case of disjunctive mappings. Or would you propose that every disjunctive mapping needs to be declared abstract?
(In reply to Christopher Gerking from comment #2) > (In reply to Adolfo Sanchez-Barbudo Herrera from comment #1) > > "abstract mappings" are mandatory when the created object is an > > "abstract" element > > Not necessarily in case of disjunctive mappings. Or would you propose that > every disjunctive mapping needs to be declared abstract? Hi Christopher, I've been erroneously mixing the concepts of operation overloading and mappings extension mechanism If mapping B inherits mapping A, and somebody calls map A, B is not executed (unless B also overloads A. In that case B and A should have the same name, proper input/output subtypes, etc.). So a mapping returning abstract elements => mapping needs to be abstract, doesn't make sense. The meaning of "abstract" still needs to be defined. Changing what I said before: - What does "abstract mapping" mean in QVTo ? An operational mapping which needs to be overloaded by at least one mapping via normal operation overloading mechanism. I still believe that isAbstract bit is needed in the AS, since we shouldn't rely on the presence of a mapping body to get that conclusion. Regards, Adolfo.
