Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Bad Examples in 8.1.10

Hi Christopher

Thanks

Example 2

result := resolveoneIn(JClass::jclass2jpackage, p : JPackage | self.packageName = p.name);


works, but trimming either of "JClass::" or "JPackage" gives errors in the editor. Trimming to just self.packageName = name gives a triple error. Looks like there are some Eclipse QVTo bugs to fix here.

Your example using a lambda-_expression_ is very interesting. The QVT AS specification gives no clue about this; just the EBNF. The implicit self within such a condition is unspecified, so maybe
self.packageName = name is not supposed to work in a similar way to an iterator _expression_.

It looks as if the

<resolve_condition> ::= <declarator> ('|' <_expression_>)?

grammar is wrong. It should be

<resolve_condition> ::= (<declarator> '|')? <_expression_>

just like an iterator body. Then the 'true' from the original specification example makes sense as the boring default _expression_. My 'return-type' are just partial declarators that have no effect.


The example is specifically showing how to bypass the re-initialization. How can Eclipse QVTo do this.

Example 4

Wow. That extra "self." is very subtle. Is there anyway to debug it?

    Regards

        Ed



On 05/10/2015 10:56, Christopher Gerking wrote:

Hi

 

 

Example 2:

 

I see no reason for premature return, at least not in this example. The resolveIn looks for an existing package which has been mapped from another class with the same package name. In case such a package is found, the result becomes non-null and the implicit instantiation section will not create a new package. There is no need to “avoid creating more than two packages having the same name” because the init section already ensures that package names are unique. And why “two”, is it a careless mistake?

 

The only reason for a premature return could be that the “name := self.packageName” initialization reexecutes unnecessarily. However there is no harm, and other ways exist to avoid that.

 

In Eclipse QVTo the init section can be rewritten more concisely as

 

result := resolveoneIn(JClass::jclass2jpackage, p : JPackage | self.packageName = p.name);

 

So yes, there are optional predicates for the target, but I also don’t understand why there is a “true” predicate.

The following is even more concise and should maybe make it to the specification:

 

result := resolveoneIn(jclass2jpackage, p | self.packageName = p.name);

 

The package name should be enough to select the resolved mapping, no need for the JCLass:: prefix. Also the p is already known as JPackage, so there should be no need for the additional : JPackage type indication.

 

 

Example 4:

 

The init section of the second mapping must be rewritten in order to update the correct Java interface. Therefore the resolveIn requires self as source:

 

mapping UML::Class::transformClassInheritance() : JAVA::Interface {

       init{

              result := self.resolveoneIn(UML::Class::transformClass);

       }

      

       base := self.superClass.resolveIn(UML::Class::transformClass);

}

 

 

Regards

Christopher

 

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Sonntag, 4. Oktober 2015 14:07
An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
Betreff: [qvto-dev] Bad Examples in 8.1.10

 

Hi

In Issue 15376 http://solitaire.omg.org/browse/QVT13-16, I complain that the examples in 8.1.10 are problematic.

The second example contains

"if result then return;"

which has a non-boolean condition _expression_ and a missing endif.

In the first example, it is not clear that the revisit adds rather than overwrites.

In the third and fourth examples it is not clear why the second pass reuses the context for the first rather than creates new objects.

5 years later this comes back to haunt me. With a slightly better understanding of QVTo, my complaints seem rather understated, the examples are quite terrible.

The attached ZIP file contains a project with launch configurations that represent my best attempt at making the examples work.

----

I cannot get the second example to work:

transformation JClass2JPackage(inout javamodel:JAVA);
main () { javamodel->objectsOfType(JClass)->jclass2jpackage();}
mapping Class::jclass2jpackage() : JPackage () {
init {
result := resolveIn(jclass2jpackage,true)
->select(p|self.package=p.name)->first();
if result then return;
}
name := self.package;
}

when changed to (JClass2JPackage.qvto):

modeltype JAVA uses 'http://www.omg.org/qvt/examples/javamodel';

transformation JClass2JPackage(inout javamodel:JAVA);
main () { javamodel.objectsOfType(JClass)->jclass2jpackage();}
mapping JClass::jclass2jpackage() : JPackage /*()*/{
init {
result := resolveIn(JClass::jclass2jpackage,JPackage)
->select(p|self.packageName=p.name)->first();
--if (result <> null) return;
}
name := self.packageName;
}

I am defeated by the "if result then return" line.

It seems that we must use () to force the imperative rather than declarative if.

Presumably we need "<> null" to ensure a Boolean condition, but Eclipse QVTo doesn't complain about this, perhaps other bugs occlude this warning.

A value-less return is diagnosed as an error so I tried "return result", so that:
 
The premature return is diagnosed as not supported by Eclipse QVTo.

Iff the premature return is really needed, then the missing support in Eclipse QVTo is bad.

But I don't understand the resolveIn at all, the second argument seems optional and undocumented. Is it an optional predicate on the return value?

The semantics of the init look very important and suspect. Presumably the resolveIn target is created before/as the init executes but even if it does, surely, JPackage::name is uninitialized so that ->first() must always return invalid since the name match fails and no successful mapping ever executes?

------

Third example using late resolve seems fine apart from typos.

------

I cannot make the fourth two-pass variant work. After changing (UML2JavaTwoPass.qvto)

transformation Uml2Java(in uml:UML,out java:JAVA)
main() : JAVA::Interface {
uml->objectsOfType(Class)->map transformClass();
uml->objectsOfType(Class)->map transformClassInheritance();
}
mapping UML::transformClass() : JAVA::Interface {
name := "Ifce".concat(self.name);
}
mapping UML::transformClassInheritance() : JAVA:Interface {
base := self.superClass->resolveIn(transformClass,JAVA::Interface);
}

to

modeltype JAVA uses 'http://www.omg.org/qvt/examples/javamodel';
modeltype UML uses 'http://www.omg.org/qvt/examples/umlmodel';

transformation Uml2Java(in uml:UML,out java:JAVA);

main() /*: JAVA::Interface*/ {
uml.objectsOfType(Class)->map transformClass();
uml.objectsOfType(Class)->map transformClassInheritance();
}
mapping UML::Class::transformClass() : JAVA::Interface {
name := "Ifce".concat(self.name);
}
mapping UML::Class::transformClassInheritance() : JAVA::Interface {
init{
result := resolveIn(UML::Class::transformClass,JAVA::Interface)->first();
}
result.base := self.superClass.resolveIn(UML::Class::transformClass,JAVA::Interface);
}


I am unable to persuade the second pass to re-use the first.

Can anyone help? Is it an Eclipse QVTo bug?

    Regards

        Ed Willink



_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10762 - Release Date: 10/05/15



Back to the top