Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » [Acceleo] null in [let] variables
[Acceleo] null in [let] variables [message #635278] Tue, 26 October 2010 05:14 Go to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi

OCL allows null to be assigned to a let variable. This is a convenient
indicator for a not-something response from a query.

However Acceleo seems to regard initialization of a [let] variable with
null as an exceuse to buy pass all intervening code.

Is there a way for a [let] variable to cache the result of say a
my-first-base-class query, which will be an object for derived classes,
but null for a root class?

Regards

Ed Willink
Re: [Acceleo] null in [let] variables [message #635286 is a reply to message #635278] Tue, 26 October 2010 05:29 Go to previous messageGo to next message
Stephane Begaudeau is currently offline Stephane Begaudeau
Messages: 406
Registered: April 2010
Location: Nantes (France)
Senior Member

Hi Edward,

The behavior that you are seeing is normal. The "let" in Acceleo is the "let' from the MTL specification not the "let" from OCL. This "let" (in the MTL specification) means "if xxx instanceof" and because null is not "instanceof" anything it won't work. You can see the MTL specification here: http://www.omg.org/spec/MOFM2T/1.0/ (page 19 for the let block).

Stephane Begaudeau, Obeo



Re: [Acceleo] null in [let] variables [message #635317 is a reply to message #635286] Tue, 26 October 2010 07:40 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1622
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090800080407000708050705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ed,

Stephane's answer is entirely correct, but to complete : you can use the
OCL 'let ... in ...' (instead of the Acceleo let block) by "tricking"
the compiler into it :

[let ....] is an Acceleo let block, but
[(let ...)] is an Acceleo "expression" block which thus lets you write
an entire OCL 'let' and will generate the result of this expression.

However, if your intent is only to "cache the result of a query", you
can simply use an Acceleo query : as per the spec "calling a query twice
with the same arguments will yield the same result",
implementation-wise, this means we cache the results of Acceleo queries.

Laurent Goubet
Obeo

Stephane Begaudeau wrote:
> Hi Edward,
>
> The behavior that you are seeing is normal. The "let" in Acceleo is the
> "let' from the MTL specification not the "let" from OCL. This "let" (in
> the MTL specification) means "if xxx instanceof" and because null is not
> "instanceof" anything it won't work. You can see the MTL specification
> here: http://www.omg.org/spec/MOFM2T/1.0/ (page 19 for the let block).
>
> Stephane Begaudeau, Obeo


--------------090800080407000708050705
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------090800080407000708050705--
Re: [Acceleo] null in [let] variables [message #635428 is a reply to message #635317] Tue, 26 October 2010 14:12 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi Stephane, Laurent

Yes, I suspected that Acceleo was accurately implementing a debatable
specification.

The query caches are often very helpful, but occasionally irritating, e.g.
when trying to generate a unique id for a String-valued object that just
happens to match
an earlier one.

Retyping queries to workaround strange [let] is hardly very sensible.

Perhaps when you take on the role of progressing the MOFM2T
specification you might consider a

'mayBeNull(true)' optional argument for a [let]

'noCache(true)' optional argument for [query]

Regards

Ed Willink
Re: [Acceleo] null in [let] variables [message #636308 is a reply to message #635428] Sat, 30 October 2010 12:36 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1622
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080206030206000402010004
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ed,

The "noCache" argument for queries is indeed something we are trying to
implement in a meaningful way (cache are irritating in some cases such
as yours ... but they can above all become a memory issue we can't force
on clients).

However, I must admit we've never given thought on something like a
"mayBeNull" option for lets ... the behavior of the let block itself
doesn't cope with that (I'd never want "null.instanceof(Something)"
return true ... ever). If anything, we should try and have the MTL
specification change the "let" behavior from an instanceof to the OCL's
let behavior. A specification so tightlty dependent on another, yet that
changes one of the keywords signification so is rather unsettling.

In short, I can isolate three potential use of the "let" keyword in
Acceleo, and two out of three have the OCL meaning :

1 - [let s : String = null]...[/let]
2 - [(let s : String = null in s)/]
3 - [query private generateNull() : String = let s : String = null in s/]

I can't say that I like this incoherence, as only "1" has the "MOFM2T"
meaning (and thus, will never generate anything), I'd rather see the
specification evolve than adding a non-standard meaning to it through
options.

Laurent Goubet
Obeo

Ed Willink wrote:
> Hi Stephane, Laurent
>
> Yes, I suspected that Acceleo was accurately implementing a debatable
> specification.
>
> The query caches are often very helpful, but occasionally irritating, e.g.
> when trying to generate a unique id for a String-valued object that just
> happens to match
> an earlier one.
>
> Retyping queries to workaround strange [let] is hardly very sensible.
>
> Perhaps when you take on the role of progressing the MOFM2T
> specification you might consider a
>
> 'mayBeNull(true)' optional argument for a [let]
>
> 'noCache(true)' optional argument for [query]
>
> Regards
>
> Ed Willink
>
>


--------------080206030206000402010004
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------080206030206000402010004--
Re: [Acceleo] null in [let] variables [message #636312 is a reply to message #636308] Sat, 30 October 2010 13:24 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi Laurent

The UML RTF have just fallen over a related issue asking what the
semantic difference is between

Integer[1] and Integer[0..1]

answer null is a well-formed value only for Integer[0..1].

This discussion pointed out an inconsistency between multiplicity based
UML operations and collection based OCL operation contexts.

OCL is therefore likely to allow bounded collection and quantified types
such as

Sequence(Integer[2])[3] - a 2x3 matrix.

and a allow either

let x : Integer[1] in ...

or

let x : Integer[0..1] in ...

Currently OCL's let is implicitly [0..1], whereas MOFM2T's let is [1].

If both evolved to allow the [0..1] or [1] suffix, the flexibility issue
is resolved.

Just a backward compatibility issue as to whether MOFM2T should really have
two so different lets.

Regards

Ed


On 30/10/2010 17:36, Laurent Goubet wrote:
> Hi Ed,
>
> The "noCache" argument for queries is indeed something we are trying
> to implement in a meaningful way (cache are irritating in some cases
> such as yours ... but they can above all become a memory issue we
> can't force on clients).
>
> However, I must admit we've never given thought on something like a
> "mayBeNull" option for lets ... the behavior of the let block itself
> doesn't cope with that (I'd never want "null.instanceof(Something)"
> return true ... ever). If anything, we should try and have the MTL
> specification change the "let" behavior from an instanceof to the
> OCL's let behavior. A specification so tightlty dependent on another,
> yet that changes one of the keywords signification so is rather
> unsettling.
>
> In short, I can isolate three potential use of the "let" keyword in
> Acceleo, and two out of three have the OCL meaning :
>
> 1 - [let s : String = null]...[/let]
> 2 - [(let s : String = null in s)/]
> 3 - [query private generateNull() : String = let s : String = null in s/]
>
> I can't say that I like this incoherence, as only "1" has the "MOFM2T"
> meaning (and thus, will never generate anything), I'd rather see the
> specification evolve than adding a non-standard meaning to it through
> options.
>
> Laurent Goubet
> Obeo
>
> Ed Willink wrote:
>> Hi Stephane, Laurent
>>
>> Yes, I suspected that Acceleo was accurately implementing a debatable
>> specification.
>>
>> The query caches are often very helpful, but occasionally irritating,
>> e.g.
>> when trying to generate a unique id for a String-valued object that
>> just happens to match
>> an earlier one.
>>
>> Retyping queries to workaround strange [let] is hardly very sensible.
>>
>> Perhaps when you take on the role of progressing the MOFM2T
>> specification you might consider a
>>
>> 'mayBeNull(true)' optional argument for a [let]
>>
>> 'noCache(true)' optional argument for [query]
>>
>> Regards
>>
>> Ed Willink
>>
>>
>
Previous Topic:Xpand: Resolving cross-references
Next Topic:[Acceleo] "Selection does not contain a main type ..."
Goto Forum:
  


Current Time: Thu Jul 31 15:40:28 EDT 2014

Powered by FUDForum. Page generated in 0.07826 seconds