[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2t-dev] [MTL] Template invocations
|
Hi Laurent,
My understanding is as follows, and it is close to what you have written.
Issue 1: The template will be invoked as many times as argument 1 has members. So for each member of argument 1 with the singleton string as argument 2.
Issue 2: The template will be invoked for each member of the cross product of the members of the arguments, regardless of these arguments' size.
Issue 3: The template will be invoked for the cross product of the members of argument 1 and argument 2, with the set argument as argument 3.
To be sure, I'll check this with TCS.
This feature makes indeed the language less strict. In your example you cannot make a choice between the two templates.
On the other hand, it is a reasonably well documented feature from the spec - it allows for really short notation of iterations which are used all the time. I'm not sure, but does OCL do the same trick - allowing Sets arguments for Singleton parameters?
It is a difficult point.
Kind Regards, Arjan.
(PS I'm on vacation the next 3 weeks).
2008/7/7 Laurent Goubet <
laurent.goubet@xxxxxxx>:
Hi Arjan,
I'm working along with Jonathan to implement a first version of the MTL
parser and evaluation engine.
The specifications troubles me about the particular point of
'TemplateInvocation'; quote :
The rules for determining which template to invoke and how
many times are as follows:
• The types of arguments should match the types of the
corresponding parameters. An argument type matches the param-
eter type when the latter is either the same type or a super
type. If the argument is a set and the parameter is a singleton,
then the template is invoked for each member of the set.
• If the argument is a set and the parameter is a set, then the
template is invoked once.
• If the argument is a singleton and the parameter is a set, then
the template is invoked once with the singleton set.
• If the template has k singleton parameters and the corresponding
arguments are sets, then the template is invoked for
each member of the cross product of the k sets.
• If a template is overridden, then the overriding template is
invoked as described earlier.
Now let's consider the template "testTemplate" defined as such :
[template public testTemplate(s1:String, s2:String)]
...
[/template]
- How is the implementation expected to behave when calling
"testTemplate" with a Set of Strings and a singleton String?
- What if I invoke this template with two Sequences of different
sizes?
For a little more fun, Let's alter "testTemplate" definition for it to
look like :
[template public testTemplate(s1:String, s2:String,
set:Set(String))]
...
[/template]
3. What will happen If I try and invoke this template with three
sets of Strings?
The specification does not state this explicitly, but I think the
second point is handled by the fact that the template will be called
for each member of the cross product of the sets, regardless of these
sets' size?
If so, should the first point be handled by invoking the template with
the cross product of the set parameters with a single-element list
containing only the singleton parameter?
As for the third issue, well I believe it crosses the first issue but
I'd like to have your input on this.
All in all, I believe that allowing such leniency in template
invocations will prove really error prone, from the development side as
much as for the user side. As a matter of example, if a File block is
defined in a template called in such manner, the user could end up with
a considerable amount of generated files (since we call the template
with a cross product) if he didn't pay enough attention to the issue.
As for the "development side" ... this leniency introduces many issues
for polymorphic resolutions among others : if I have two templates of
the same name, the first having parameters "String, Set(String)" and
the second "String, String", which should I choose when the user wants
to invoke this template with two sets of Strings?
Regards,
Laurent Goubet
Obeo
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev