|
|
| Re: [Acceleo] null in [let] variables [message #635317 is a reply to message #635286] |
Tue, 26 October 2010 11:40   |
|
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 #636308 is a reply to message #635428] |
Sat, 30 October 2010 16:36 |
|
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 17:24 |
 Ed Willink
Messages: 7655
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
>>
>>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03473 seconds
] 
Search
Help
Register
Login
Home
