[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2t-dev] [MTL] discussion about the specification
|
Arjan,
"There is a section 8.4 in the
specification that addresses white space handling."
Let's take a simple example:
[template myScript(c:Class)]
[for (a:Property|
c.ownedAttributes)]
[mySubScript(a)/]
[/for]
[/template]
[template mySubScript(a:Property)]
['']
[/template]
I have 3 attributes in my class ('c')...
Wich one is the good result when I call "myScript(c:Class)"?
- Result1: '\n\n\n'
- Result2: ''
"I like that too, but then I
prefer to write String\[\] tab [subTemplate/];"
Perhaps '\' isn't a good idea, it is quite complex.... Can we consider
that the user has to write "String ['['] [']'] tab [subTemplate/];"
"PS I think it should be
possible to specify more than one input model."
I agree, the metamodel goes in that way but not the grammar... I have
choosen to follow the metamodel ;-)
Sometimes, the metamodel wins... sometimes it's the grammar ;-)
ANOTHER important thing :
I agree with Nuria, there is an ambiguity between TemplateInvocation
and OCLExpression in the grammar,
It is dificult to choose between a "template invocation" or a simple
"OCL _expression_" in the following example?
[myHelper(a)/]
ANOTHER important thing :
In my opinion, we don't need all the "invocation" elements in the
abstract syntax
An "invocation" is often like an OCL operation ref....
I think that it could be very usefull to consider a template like a
function that always returns a StringLiteralExpression
and I would like to be allowed to call a template on the first
parameter, like in the following example :
[template myScript(c:Class)]
[for (a:Property| c.ownedAttributes)]
[mySubScript(a,c)/]
[a.mySubScript(c).trim()/]!!!!!!!!!!!!!!! it isn't possible at
the moment, but I would like your opinion OMG guys ;-)
[/for]
[/template]
[template mySubScript(a:Property, c:Class)]
[/template]
Regards,
Jonathan
Arjan Kok a écrit :
Hi,
For those that do not know
me, my name is Arjan Kok and I was one of the main contributors to the
OMG mof model to text specification. I think it is really important to
get a good open source implementation of the spec. I'll comment on the
questions.
- When an
invocation creates an empty line :
Does it mean that
we have to generate "\n" or ""?
I do not understand. There
is a section 8.4 in the specification that addresses white space
handling.
- For the abstract syntax, there are a lot of namings and
multiplicities issues : "arguments" mustn't end with 's'
Ok. Sorry for that.
- Can we use MANIFEST.MF files to declare dependencies between
generation modules?
I would like to
use the eclipse mecanism for dependencies but it is not compatible with
the specification
I think it is a good idea
to use osgi to declare the dependencies between modules. I think you
need something like a uri-resolver. Why is it not compatible with the
spec?
- There is a confusion for the "escape" character, the specification
defines a way to change the delimiters using an annotation (@delimiter=)
but sometimes I
would like to use a simple escape character like in java ('\'), more
usefull and readable
For example, I
want to generate : String[] tab = "";
I think that the
following template is quite simple to write : String\[] tab
[subTemplate/];
I like that too, but then I
prefer to write String\[\] tab [subTemplate/];
- The delimiters of the protected area are not defined in the standard,
they don't want to make a choice
So, We have to
choose the way to keep the user code...
We can use tags
like : //Start of user code //End of user code
I would like to
dicuss about the different points of views?
I think leaving the
delimiters to the implementation is an error in the spec, because it
will lead to interoperability problems. Note that the id of the text
parts should be unique (see example 3).
- TemplateInvocation : The specification is ambiguous if the result is
not a string... Is it an error? Do We have to call the toString by
default?
Its all about producing
text, so toString()
- String libraries are different between the QVT and the MTL
specifications : for example firstUpper() != upperFirst()
The priority for
us is to be as near as possible of the QVT library
Yes, that was the intention.
- Module.import reference is missing in the metamodel... We decided to
create an import link in the metamodel...
Ok.
- We need the position of the template element during the
generation (for the debugger)
So, We defined a
new element to store the position information
Ok
I'll be really happy to have more points of view ;-)
PS I think it should be
possible to specify more than one input model.
Kind Regards, Arjan
On Mon, May 26, 2008 at 3:02 PM, Jonathan
MUSSET < jonathan.musset@xxxxxxx>
wrote:
Hi
everybody
We've got a first version of the MTL parser on the CVS
It means that we can create an abstract representation of the
templates. The AST is based on an EMF metamodel.
Here is an example of a MTL template (for those who don't know the MTL
syntax) :
[module mymodule(http://www.eclipse.org/uml2/2.1.0/UML)/]
[template public classToJava(a:Property, c:Class)]
[if (1 = (1 + c.ownedAttribute->size() + a->type->size() +
c->size()))]
[if (c.attribute->size())]
aaa
[elseif (a->type.name)]
bbb
[else]
ccc
[/if]
[/if]
[for (p : Operation | c ->ownedOperation.type)]
ddd[p.name/]
[/for]
[/template]
The metamodel is also based on the OCL metamodel of the MDT project.
According to the Model-To-Text specification, We have to use the
classes ocl.OCLExpression and ocl.Variable...
Now, Laurent is working more actively on the generation engine.
The architecture of this standalone engine will probably be a
combination of this MTL AST, the m2t backend, and the MDT-OCL execution
environnement...
We had a lot of problems with the specification...
Arjan and Me have worked a long time on the ambiguities of the
specification.
Arjan, Do you have any feedbacks from the OMG guys?
I would like to dicuss more about these ambiguities with those who know
the specification...
I think that this mailing list is a good place to make choice for the
eclipse implementation of this specification
Don't hesitate to share your experiences and your point of view
Here are some examples of ambiguities that We have detected :
- When an invocation creates an empty line :
Does it mean that we have to generate "\n" or ""?
- For the abstract syntax, there are a lot of namings and
multiplicities issues : "arguments" mustn't end with 's'
- Can we use MANIFEST.MF files to declare dependencies between
generation modules?
I would like to use the eclipse mecanism for dependencies but it is
not compatible with the specification
- There is a confusion for the "escape" character, the specification
defines a way to change the delimiters using an annotation (@delimiter=)
but sometimes I would like to use a simple escape character like in
java ('\'), more usefull and readable
For example, I want to generate : String[] tab = "";
I think that the following template is quite simple to write :
String\[] tab [subTemplate/];
- The delimiters of the protected area are not defined in the standard,
they don't want to make a choice
So, We have to choose the way to keep the user code...
We can use tags like : //Start of user code //End of user code
I would like to dicuss about the different points of views?
- TemplateInvocation : The specification is ambiguous if the result is
not a string... Is it an error? Do We have to call the toString by
default?
- String libraries are different between the QVT and the MTL
specifications : for example firstUpper() != upperFirst()
The priority for us is to be as near as possible of the QVT library
- Module.import reference is missing in the metamodel... We decided to
create an import link in the metamodel...
- We need the position of the template element during the generation
(for the debugger)
So, We defined a new element to store the position information
I'll be really happy to have more points of view ;-)
Thank you
Cheers,
Jonathan
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
|
begin:vcard
fn:Jonathan MUSSET
n:MUSSET;Jonathan
org:Obeo - Model Driven Company
email;internet:jonathan.musset@xxxxxxx
title:Directeur Technique
tel;work:02 51 13 54 18
version:2.1
end:vcard