Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » Unsettable attribute, intrinsic defaults
Unsettable attribute, intrinsic defaults [message #1001994] Thu, 17 January 2013 17:18 Go to next message
Eclipse UserFriend
Hello,

given the following simple assignment:

result.floatval := self.floatval;

Both models define "floatval" as an unsettable, lowerBound=0 attribute
of type EFloat. The input model actually is an ecore model as generated
by the XSDEcoreBuilder.

Here's the problem I'm facing: if the input value is unset, then the QVT
engine still ends up in assigning the intrinsic default value of float,
which is defined in
org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
result would have been that the lvalue remains unset.

Note this special handling is only done for primitive types. For
example, for all xs:integer based types in our XSD model it works,
because those are mapped to java.lang.BigInteger.

I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
or a QVT bug. I traced
QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
could not identify that QVT even cares for unset input attributes.

TIA for any insights!

Marius
Re: Unsettable attribute, intrinsic defaults [message #1002036 is a reply to message #1001994] Thu, 17 January 2013 19:52 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

My expectation is that if some output is unSettable, it should not be
set, so specifying a QVTo assignment should be a compiler error; please
raise a Bugzilla.

If you omit the QVTo assignment, the only 'set' should be EMF's default
initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
this is even possible. If it's unsettable, any eSet should barf.

On the input side, I would not expect QVTo to take any notice of
isSettable. It's just a value source that happens to have a frozen default.

Regards

Ed Willink

On 17/01/2013 17:18, Marius Gröger wrote:
> Hello,
>
> given the following simple assignment:
>
> result.floatval := self.floatval;
>
> Both models define "floatval" as an unsettable, lowerBound=0 attribute
> of type EFloat. The input model actually is an ecore model as generated
> by the XSDEcoreBuilder.
>
> Here's the problem I'm facing: if the input value is unset, then the QVT
> engine still ends up in assigning the intrinsic default value of float,
> which is defined in
> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
> result would have been that the lvalue remains unset.
>
> Note this special handling is only done for primitive types. For
> example, for all xs:integer based types in our XSD model it works,
> because those are mapped to java.lang.BigInteger.
>
> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
> or a QVT bug. I traced
> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
> could not identify that QVT even cares for unset input attributes.
>
> TIA for any insights!
>
> Marius
Re: Unsettable attribute, intrinsic defaults [message #1002217 is a reply to message #1002036] Fri, 18 January 2013 07:41 Go to previous messageGo to next message
Eclipse UserFriend
Hi Ed,

thanks for your answer. Reading it made me realize that I misunderstood
the meaning of "unsettable". I was under the impression that it means
"can be unset", but it really means "cannot be set".

This misunderstanding led me to a false description of the issue. So
here I go again with the corrected description:

Given the following simple assignment:

result.floatval := self.floatval;

Both models define "floatval" as a settable, lowerBound=0 attribute
of type EFloat. The input model actually is an ecore model as generated
by the XSDEcoreBuilder.

Here's the problem I'm facing: if the input value is unset, then the QVT
engine still ends up in assigning the intrinsic default value of float,
which is defined in
org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
result would have been that the lvalue remains unset, because the rvalue
is unset as well.

TIA
Marius

On 17.01.2013 20:52, Ed Willink wrote:
> Hi
>
> My expectation is that if some output is unSettable, it should not be
> set, so specifying a QVTo assignment should be a compiler error; please
> raise a Bugzilla.
>
> If you omit the QVTo assignment, the only 'set' should be EMF's default
> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
> this is even possible. If it's unsettable, any eSet should barf.
>
> On the input side, I would not expect QVTo to take any notice of
> isSettable. It's just a value source that happens to have a frozen default.
>
> Regards
>
> Ed Willink
>
> On 17/01/2013 17:18, Marius Gröger wrote:
>> Hello,
>>
>> given the following simple assignment:
>>
>> result.floatval := self.floatval;
>>
>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>> of type EFloat. The input model actually is an ecore model as generated
>> by the XSDEcoreBuilder.
>>
>> Here's the problem I'm facing: if the input value is unset, then the QVT
>> engine still ends up in assigning the intrinsic default value of float,
>> which is defined in
>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>> result would have been that the lvalue remains unset.
>>
>> Note this special handling is only done for primitive types. For
>> example, for all xs:integer based types in our XSD model it works,
>> because those are mapped to java.lang.BigInteger.
>>
>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>> or a QVT bug. I traced
>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
>> could not identify that QVT even cares for unset input attributes.
>>
>> TIA for any insights!
>>
>> Marius
>
Re: Unsettable attribute, intrinsic defaults [message #1002232 is a reply to message #1002217] Fri, 18 January 2013 08:17 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

No. Unset, means that it has not been explicitly set and so retains its
initial value. It does not mean that it contains a distinct out-of-band
value. So a transformation should indeed transfer this value. Just
possibly in an Eclipse tool if the transferred value is identical to the
default value the transfer could be done without actually setting the
default explicitly.

However unset is an Ecore rather than EMOF concept, so there is no OMG
specification for this in OCL or QVT.

If unset was supported, one would need to define whether an update
transformation sets the unchanged values, in which case there could be
an inconsistency between a created output and an unchanged refreshed
output. Would need some careful study.

So no bug. QVTo like many tools is free to perform redundant sets when
creating EObjects.

Regards

Ed Willink


On 18/01/2013 07:41, Marius Gröger wrote:
> Hi Ed,
>
> thanks for your answer. Reading it made me realize that I misunderstood
> the meaning of "unsettable". I was under the impression that it means
> "can be unset", but it really means "cannot be set".
>
> This misunderstanding led me to a false description of the issue. So
> here I go again with the corrected description:
>
> Given the following simple assignment:
>
> result.floatval := self.floatval;
>
> Both models define "floatval" as a settable, lowerBound=0 attribute
> of type EFloat. The input model actually is an ecore model as generated
> by the XSDEcoreBuilder.
>
> Here's the problem I'm facing: if the input value is unset, then the QVT
> engine still ends up in assigning the intrinsic default value of float,
> which is defined in
> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
> result would have been that the lvalue remains unset, because the rvalue
> is unset as well.
>
> TIA
> Marius
>
> On 17.01.2013 20:52, Ed Willink wrote:
>> Hi
>>
>> My expectation is that if some output is unSettable, it should not be
>> set, so specifying a QVTo assignment should be a compiler error; please
>> raise a Bugzilla.
>>
>> If you omit the QVTo assignment, the only 'set' should be EMF's default
>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>> this is even possible. If it's unsettable, any eSet should barf.
>>
>> On the input side, I would not expect QVTo to take any notice of
>> isSettable. It's just a value source that happens to have a frozen default.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 17/01/2013 17:18, Marius Gröger wrote:
>>> Hello,
>>>
>>> given the following simple assignment:
>>>
>>> result.floatval := self.floatval;
>>>
>>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>>> of type EFloat. The input model actually is an ecore model as generated
>>> by the XSDEcoreBuilder.
>>>
>>> Here's the problem I'm facing: if the input value is unset, then the QVT
>>> engine still ends up in assigning the intrinsic default value of float,
>>> which is defined in
>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>>> result would have been that the lvalue remains unset.
>>>
>>> Note this special handling is only done for primitive types. For
>>> example, for all xs:integer based types in our XSD model it works,
>>> because those are mapped to java.lang.BigInteger.
>>>
>>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>>> or a QVT bug. I traced
>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
>>> could not identify that QVT even cares for unset input attributes.
>>>
>>> TIA for any insights!
>>>
>>> Marius
Re: Unsettable attribute, intrinsic defaults [message #1002255 is a reply to message #1002232] Fri, 18 January 2013 08:58 Go to previous messageGo to next message
Eclipse UserFriend
Hello Ed,

thanks for your explanation. In the meantime I have done some reading
and found that my initial understanding "unset" was correct after all:
it means the value has not been assigned a value.

So my issue boils down to the fact that EMF, for primitive type, always
has an intrinsic default value. It is this value that QVT will then
transfer. For non-primitive types, the value is also transfered, but
that value is null and so the output attribute remains being unset.

I think I will take it to the EMF group to find out how to best handle this.

Thanks again
Marius

On 18.01.2013 09:17, Ed Willink wrote:
> Hi
>
> No. Unset, means that it has not been explicitly set and so retains its
> initial value. It does not mean that it contains a distinct out-of-band
> value. So a transformation should indeed transfer this value. Just
> possibly in an Eclipse tool if the transferred value is identical to the
> default value the transfer could be done without actually setting the
> default explicitly.
>
> However unset is an Ecore rather than EMOF concept, so there is no OMG
> specification for this in OCL or QVT.
>
> If unset was supported, one would need to define whether an update
> transformation sets the unchanged values, in which case there could be
> an inconsistency between a created output and an unchanged refreshed
> output. Would need some careful study.
>
> So no bug. QVTo like many tools is free to perform redundant sets when
> creating EObjects.
>
> Regards
>
> Ed Willink
>
>
> On 18/01/2013 07:41, Marius Gröger wrote:
>> Hi Ed,
>>
>> thanks for your answer. Reading it made me realize that I misunderstood
>> the meaning of "unsettable". I was under the impression that it means
>> "can be unset", but it really means "cannot be set".
>>
>> This misunderstanding led me to a false description of the issue. So
>> here I go again with the corrected description:
>>
>> Given the following simple assignment:
>>
>> result.floatval := self.floatval;
>>
>> Both models define "floatval" as a settable, lowerBound=0 attribute
>> of type EFloat. The input model actually is an ecore model as generated
>> by the XSDEcoreBuilder.
>>
>> Here's the problem I'm facing: if the input value is unset, then the QVT
>> engine still ends up in assigning the intrinsic default value of float,
>> which is defined in
>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>> result would have been that the lvalue remains unset, because the rvalue
>> is unset as well.
>>
>> TIA
>> Marius
>>
>> On 17.01.2013 20:52, Ed Willink wrote:
>>> Hi
>>>
>>> My expectation is that if some output is unSettable, it should not be
>>> set, so specifying a QVTo assignment should be a compiler error; please
>>> raise a Bugzilla.
>>>
>>> If you omit the QVTo assignment, the only 'set' should be EMF's default
>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>> this is even possible. If it's unsettable, any eSet should barf.
>>>
>>> On the input side, I would not expect QVTo to take any notice of
>>> isSettable. It's just a value source that happens to have a frozen
>>> default.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>> Hello,
>>>>
>>>> given the following simple assignment:
>>>>
>>>> result.floatval := self.floatval;
>>>>
>>>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>>>> of type EFloat. The input model actually is an ecore model as generated
>>>> by the XSDEcoreBuilder.
>>>>
>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>> QVT
>>>> engine still ends up in assigning the intrinsic default value of float,
>>>> which is defined in
>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>> expected
>>>> result would have been that the lvalue remains unset.
>>>>
>>>> Note this special handling is only done for primitive types. For
>>>> example, for all xs:integer based types in our XSD model it works,
>>>> because those are mapped to java.lang.BigInteger.
>>>>
>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>>>> or a QVT bug. I traced
>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>> bug
>>>> could not identify that QVT even cares for unset input attributes.
>>>>
>>>> TIA for any insights!
>>>>
>>>> Marius
>
Re: Unsettable attribute, intrinsic defaults [message #1002280 is a reply to message #1002255] Fri, 18 January 2013 09:55 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

It is not the type that is unset; it is the reference to the type that
is unset, so there should be no difference for primitive types. EMF
maintains a distinct out-of-band is_set eFlags bit for the case where
there is no in-band value that can be used.

QVTo has no specification for this bit.

If explicit-set/default is so important to you, I suggest that you model
it explicitly rather than rely on under-specified implementation details.

Regards

Ed Willink


On 18/01/2013 08:58, Marius Gröger wrote:
> Hello Ed,
>
> thanks for your explanation. In the meantime I have done some reading
> and found that my initial understanding "unset" was correct after all:
> it means the value has not been assigned a value.
>
> So my issue boils down to the fact that EMF, for primitive type, always
> has an intrinsic default value. It is this value that QVT will then
> transfer. For non-primitive types, the value is also transfered, but
> that value is null and so the output attribute remains being unset.
>
> I think I will take it to the EMF group to find out how to best handle this.
>
> Thanks again
> Marius
>
> On 18.01.2013 09:17, Ed Willink wrote:
>> Hi
>>
>> No. Unset, means that it has not been explicitly set and so retains its
>> initial value. It does not mean that it contains a distinct out-of-band
>> value. So a transformation should indeed transfer this value. Just
>> possibly in an Eclipse tool if the transferred value is identical to the
>> default value the transfer could be done without actually setting the
>> default explicitly.
>>
>> However unset is an Ecore rather than EMOF concept, so there is no OMG
>> specification for this in OCL or QVT.
>>
>> If unset was supported, one would need to define whether an update
>> transformation sets the unchanged values, in which case there could be
>> an inconsistency between a created output and an unchanged refreshed
>> output. Would need some careful study.
>>
>> So no bug. QVTo like many tools is free to perform redundant sets when
>> creating EObjects.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 18/01/2013 07:41, Marius Gröger wrote:
>>> Hi Ed,
>>>
>>> thanks for your answer. Reading it made me realize that I misunderstood
>>> the meaning of "unsettable". I was under the impression that it means
>>> "can be unset", but it really means "cannot be set".
>>>
>>> This misunderstanding led me to a false description of the issue. So
>>> here I go again with the corrected description:
>>>
>>> Given the following simple assignment:
>>>
>>> result.floatval := self.floatval;
>>>
>>> Both models define "floatval" as a settable, lowerBound=0 attribute
>>> of type EFloat. The input model actually is an ecore model as generated
>>> by the XSDEcoreBuilder.
>>>
>>> Here's the problem I'm facing: if the input value is unset, then the QVT
>>> engine still ends up in assigning the intrinsic default value of float,
>>> which is defined in
>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>>> result would have been that the lvalue remains unset, because the rvalue
>>> is unset as well.
>>>
>>> TIA
>>> Marius
>>>
>>> On 17.01.2013 20:52, Ed Willink wrote:
>>>> Hi
>>>>
>>>> My expectation is that if some output is unSettable, it should not be
>>>> set, so specifying a QVTo assignment should be a compiler error; please
>>>> raise a Bugzilla.
>>>>
>>>> If you omit the QVTo assignment, the only 'set' should be EMF's default
>>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>>> this is even possible. If it's unsettable, any eSet should barf.
>>>>
>>>> On the input side, I would not expect QVTo to take any notice of
>>>> isSettable. It's just a value source that happens to have a frozen
>>>> default.
>>>>
>>>> Regards
>>>>
>>>> Ed Willink
>>>>
>>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>>> Hello,
>>>>>
>>>>> given the following simple assignment:
>>>>>
>>>>> result.floatval := self.floatval;
>>>>>
>>>>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>>>>> of type EFloat. The input model actually is an ecore model as generated
>>>>> by the XSDEcoreBuilder.
>>>>>
>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>> QVT
>>>>> engine still ends up in assigning the intrinsic default value of float,
>>>>> which is defined in
>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>> expected
>>>>> result would have been that the lvalue remains unset.
>>>>>
>>>>> Note this special handling is only done for primitive types. For
>>>>> example, for all xs:integer based types in our XSD model it works,
>>>>> because those are mapped to java.lang.BigInteger.
>>>>>
>>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>>>>> or a QVT bug. I traced
>>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>>> bug
>>>>> could not identify that QVT even cares for unset input attributes.
>>>>>
>>>>> TIA for any insights!
>>>>>
>>>>> Marius
Re: Unsettable attribute, intrinsic defaults [message #1002347 is a reply to message #1002280] Fri, 18 January 2013 12:36 Go to previous messageGo to next message
Eclipse UserFriend
Hello,

I'm afraid explicitly modeling set/unset would be overly complicate the
XSD model. The XML instance is perfectly able to represent the unset
case, and so is my internal EMF model. It's just a shame that during the
QVT conversion, EMF sneaks in an intrinsic default for all primitive
types. I'm currently looking into changing this behavior in EMF's
XSDEcoreBuilder, but it doesn't look very promising.

Marius

On 18.01.2013 10:55, Ed Willink wrote:
> Hi
>
> It is not the type that is unset; it is the reference to the type that
> is unset, so there should be no difference for primitive types. EMF
> maintains a distinct out-of-band is_set eFlags bit for the case where
> there is no in-band value that can be used.
>
> QVTo has no specification for this bit.
>
> If explicit-set/default is so important to you, I suggest that you model
> it explicitly rather than rely on under-specified implementation details.
>
> Regards
>
> Ed Willink
>
>
> On 18/01/2013 08:58, Marius Gröger wrote:
>> Hello Ed,
>>
>> thanks for your explanation. In the meantime I have done some reading
>> and found that my initial understanding "unset" was correct after all:
>> it means the value has not been assigned a value.
>>
>> So my issue boils down to the fact that EMF, for primitive type, always
>> has an intrinsic default value. It is this value that QVT will then
>> transfer. For non-primitive types, the value is also transfered, but
>> that value is null and so the output attribute remains being unset.
>>
>> I think I will take it to the EMF group to find out how to best handle
>> this.
>>
>> Thanks again
>> Marius
>>
>> On 18.01.2013 09:17, Ed Willink wrote:
>>> Hi
>>>
>>> No. Unset, means that it has not been explicitly set and so retains its
>>> initial value. It does not mean that it contains a distinct out-of-band
>>> value. So a transformation should indeed transfer this value. Just
>>> possibly in an Eclipse tool if the transferred value is identical to the
>>> default value the transfer could be done without actually setting the
>>> default explicitly.
>>>
>>> However unset is an Ecore rather than EMOF concept, so there is no OMG
>>> specification for this in OCL or QVT.
>>>
>>> If unset was supported, one would need to define whether an update
>>> transformation sets the unchanged values, in which case there could be
>>> an inconsistency between a created output and an unchanged refreshed
>>> output. Would need some careful study.
>>>
>>> So no bug. QVTo like many tools is free to perform redundant sets when
>>> creating EObjects.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>>
>>> On 18/01/2013 07:41, Marius Gröger wrote:
>>>> Hi Ed,
>>>>
>>>> thanks for your answer. Reading it made me realize that I misunderstood
>>>> the meaning of "unsettable". I was under the impression that it means
>>>> "can be unset", but it really means "cannot be set".
>>>>
>>>> This misunderstanding led me to a false description of the issue. So
>>>> here I go again with the corrected description:
>>>>
>>>> Given the following simple assignment:
>>>>
>>>> result.floatval := self.floatval;
>>>>
>>>> Both models define "floatval" as a settable, lowerBound=0 attribute
>>>> of type EFloat. The input model actually is an ecore model as generated
>>>> by the XSDEcoreBuilder.
>>>>
>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>> QVT
>>>> engine still ends up in assigning the intrinsic default value of float,
>>>> which is defined in
>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>> expected
>>>> result would have been that the lvalue remains unset, because the
>>>> rvalue
>>>> is unset as well.
>>>>
>>>> TIA
>>>> Marius
>>>>
>>>> On 17.01.2013 20:52, Ed Willink wrote:
>>>>> Hi
>>>>>
>>>>> My expectation is that if some output is unSettable, it should not be
>>>>> set, so specifying a QVTo assignment should be a compiler error;
>>>>> please
>>>>> raise a Bugzilla.
>>>>>
>>>>> If you omit the QVTo assignment, the only 'set' should be EMF's
>>>>> default
>>>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>>>> this is even possible. If it's unsettable, any eSet should barf.
>>>>>
>>>>> On the input side, I would not expect QVTo to take any notice of
>>>>> isSettable. It's just a value source that happens to have a frozen
>>>>> default.
>>>>>
>>>>> Regards
>>>>>
>>>>> Ed Willink
>>>>>
>>>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>>>> Hello,
>>>>>>
>>>>>> given the following simple assignment:
>>>>>>
>>>>>> result.floatval := self.floatval;
>>>>>>
>>>>>> Both models define "floatval" as an unsettable, lowerBound=0
>>>>>> attribute
>>>>>> of type EFloat. The input model actually is an ecore model as
>>>>>> generated
>>>>>> by the XSDEcoreBuilder.
>>>>>>
>>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>>> QVT
>>>>>> engine still ends up in assigning the intrinsic default value of
>>>>>> float,
>>>>>> which is defined in
>>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>>> expected
>>>>>> result would have been that the lvalue remains unset.
>>>>>>
>>>>>> Note this special handling is only done for primitive types. For
>>>>>> example, for all xs:integer based types in our XSD model it works,
>>>>>> because those are mapped to java.lang.BigInteger.
>>>>>>
>>>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF
>>>>>> bug,
>>>>>> or a QVT bug. I traced
>>>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>>>> bug
>>>>>> could not identify that QVT even cares for unset input attributes.
>>>>>>
>>>>>> TIA for any insights!
>>>>>>
>>>>>> Marius
>
Re: Unsettable attribute, intrinsic defaults [message #1002357 is a reply to message #1002347] Fri, 18 January 2013 13:00 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I can see a QVTo change on efficiency grounds to the effect that every
eSet to the output model is guarded by an if-necessary test.

This would avoid numerous redundant notifications for the in-place
update usage.

This would also solve your immediate problem, but probably then provoke
the opposite; output values that just happen to be right by default
would not be explicitly set.

If so then QVTo may be needs four eSet modes:
- always eSet
- always eSet unless value is correct and source is explictly unset
- only eSet if necessary to change a value
- only eSet if necessary to change a value or source is explicitly set

Since the source is an arbitrary OCL expression, special casing the
trivial PropertyCallExp makes me uncomfortable, and why can't you
control unset for more complex cases?

Surely you can control unset on the output by wrapping the assignment in
an imperative if? Then you just need a helper function to allow you to
test whether a source value is unset.

Regards

Ed Willink

On 18/01/2013 12:36, Marius Gröger wrote:
> Hello,
>
> I'm afraid explicitly modeling set/unset would be overly complicate the
> XSD model. The XML instance is perfectly able to represent the unset
> case, and so is my internal EMF model. It's just a shame that during the
> QVT conversion, EMF sneaks in an intrinsic default for all primitive
> types. I'm currently looking into changing this behavior in EMF's
> XSDEcoreBuilder, but it doesn't look very promising.
>
> Marius
>
> On 18.01.2013 10:55, Ed Willink wrote:
>> Hi
>>
>> It is not the type that is unset; it is the reference to the type that
>> is unset, so there should be no difference for primitive types. EMF
>> maintains a distinct out-of-band is_set eFlags bit for the case where
>> there is no in-band value that can be used.
>>
>> QVTo has no specification for this bit.
>>
>> If explicit-set/default is so important to you, I suggest that you model
>> it explicitly rather than rely on under-specified implementation details.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 18/01/2013 08:58, Marius Gröger wrote:
>>> Hello Ed,
>>>
>>> thanks for your explanation. In the meantime I have done some reading
>>> and found that my initial understanding "unset" was correct after all:
>>> it means the value has not been assigned a value.
>>>
>>> So my issue boils down to the fact that EMF, for primitive type, always
>>> has an intrinsic default value. It is this value that QVT will then
>>> transfer. For non-primitive types, the value is also transfered, but
>>> that value is null and so the output attribute remains being unset.
>>>
>>> I think I will take it to the EMF group to find out how to best handle
>>> this.
>>>
>>> Thanks again
>>> Marius
>>>
>>> On 18.01.2013 09:17, Ed Willink wrote:
>>>> Hi
>>>>
>>>> No. Unset, means that it has not been explicitly set and so retains its
>>>> initial value. It does not mean that it contains a distinct out-of-band
>>>> value. So a transformation should indeed transfer this value. Just
>>>> possibly in an Eclipse tool if the transferred value is identical to the
>>>> default value the transfer could be done without actually setting the
>>>> default explicitly.
>>>>
>>>> However unset is an Ecore rather than EMOF concept, so there is no OMG
>>>> specification for this in OCL or QVT.
>>>>
>>>> If unset was supported, one would need to define whether an update
>>>> transformation sets the unchanged values, in which case there could be
>>>> an inconsistency between a created output and an unchanged refreshed
>>>> output. Would need some careful study.
>>>>
>>>> So no bug. QVTo like many tools is free to perform redundant sets when
>>>> creating EObjects.
>>>>
>>>> Regards
>>>>
>>>> Ed Willink
>>>>
>>>>
>>>> On 18/01/2013 07:41, Marius Gröger wrote:
>>>>> Hi Ed,
>>>>>
>>>>> thanks for your answer. Reading it made me realize that I misunderstood
>>>>> the meaning of "unsettable". I was under the impression that it means
>>>>> "can be unset", but it really means "cannot be set".
>>>>>
>>>>> This misunderstanding led me to a false description of the issue. So
>>>>> here I go again with the corrected description:
>>>>>
>>>>> Given the following simple assignment:
>>>>>
>>>>> result.floatval := self.floatval;
>>>>>
>>>>> Both models define "floatval" as a settable, lowerBound=0 attribute
>>>>> of type EFloat. The input model actually is an ecore model as generated
>>>>> by the XSDEcoreBuilder.
>>>>>
>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>> QVT
>>>>> engine still ends up in assigning the intrinsic default value of float,
>>>>> which is defined in
>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>> expected
>>>>> result would have been that the lvalue remains unset, because the
>>>>> rvalue
>>>>> is unset as well.
>>>>>
>>>>> TIA
>>>>> Marius
>>>>>
>>>>> On 17.01.2013 20:52, Ed Willink wrote:
>>>>>> Hi
>>>>>>
>>>>>> My expectation is that if some output is unSettable, it should not be
>>>>>> set, so specifying a QVTo assignment should be a compiler error;
>>>>>> please
>>>>>> raise a Bugzilla.
>>>>>>
>>>>>> If you omit the QVTo assignment, the only 'set' should be EMF's
>>>>>> default
>>>>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>>>>> this is even possible. If it's unsettable, any eSet should barf.
>>>>>>
>>>>>> On the input side, I would not expect QVTo to take any notice of
>>>>>> isSettable. It's just a value source that happens to have a frozen
>>>>>> default.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Ed Willink
>>>>>>
>>>>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> given the following simple assignment:
>>>>>>>
>>>>>>> result.floatval := self.floatval;
>>>>>>>
>>>>>>> Both models define "floatval" as an unsettable, lowerBound=0
>>>>>>> attribute
>>>>>>> of type EFloat. The input model actually is an ecore model as
>>>>>>> generated
>>>>>>> by the XSDEcoreBuilder.
>>>>>>>
>>>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>>>> QVT
>>>>>>> engine still ends up in assigning the intrinsic default value of
>>>>>>> float,
>>>>>>> which is defined in
>>>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>>>> expected
>>>>>>> result would have been that the lvalue remains unset.
>>>>>>>
>>>>>>> Note this special handling is only done for primitive types. For
>>>>>>> example, for all xs:integer based types in our XSD model it works,
>>>>>>> because those are mapped to java.lang.BigInteger.
>>>>>>>
>>>>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF
>>>>>>> bug,
>>>>>>> or a QVT bug. I traced
>>>>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>>>>> bug
>>>>>>> could not identify that QVT even cares for unset input attributes.
>>>>>>>
>>>>>>> TIA for any insights!
>>>>>>>
>>>>>>> Marius
Re: Unsettable attribute, intrinsic defaults [message #1002385 is a reply to message #1002357] Fri, 18 January 2013 13:39 Go to previous messageGo to next message
Eclipse UserFriend
On 18.01.2013 14:00, Ed Willink wrote:
> Surely you can control unset on the output by wrapping the assignment in
> an imperative if? Then you just need a helper function to allow you to
> test whether a source value is unset.

Meaning to analyse the source as an EObject and checking eIsSet()?
Probably, but it would really mess up the QVT code a lot. And I really
only see this issue with primitive floats.

I just posted a work-around on e.t.emf in the thread 'Annoying intrinsic
default values for primitive types'. That solution concerns XSD models.
Regular Ecore models won't be affected by this as long as all values are
put into custom EDataTypes, ie. if EInt, EFloat etc are avoided.

Regards
Marius
Re: Unsettable attribute, intrinsic defaults [message #1002426 is a reply to message #1002385] Fri, 18 January 2013 14:55 Go to previous messageGo to next message
Alan McMorran is currently offline Alan McMorranFriend
Messages: 55
Registered: July 2009
Member
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1138.51">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #3344fc}
p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #921e67; min-height: 15.0px}
p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p6 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #921e67}
p.p7 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #0034c9}
p.p8 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p9 {margin: 0.0px 0.0px 0.0px 12.0px; line-height: 14.0px; font: 12.0px Helvetica; color: #002390}
p.p10 {margin: 0.0px 0.0px 0.0px 24.0px; font: 12.0px Helvetica; color: #008d12}
p.p11 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390; min-height: 14.0px}
p.p12 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390}
p.p13 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #000000; min-height: 14.0px}
span.s1 {color: #921e67}
span.s2 {color: #000000}
span.s3 {color: #83195c}
span.s4 {color: #002cae}
span.s5 {color: #0034c9}
span.s6 {color: #3344fc}
span.Apple-tab-span {white-space:pre}
</style>
</head>
<body>
<p class="p1">I ran into this problem and my solution is to sort of cheat a bit and add a Helper method:</p>
<p class="p2"><br></p>
<p class="p3"><span class="s1">modeltype</span><span class="s2"> ECORE </span><span class="s1">uses</span><span class="s2"> </span>'http://www.eclipse.org/emf/2002/Ecore'<span class="s2">;</span></p>
<p class="p4"><br></p>
<p class="p5"><span class="s1">helper</span> OclAny::<span class="s3">isSet</span>(feature : String) : Boolean{</p>
<p class="p5"><span class="Apple-tab-span"> </span><span class="s1">var</span> value : Boolean := <span class="s1">false</span>;</p>
<p class="p5"><span class="Apple-tab-span"> </span><span class="s1">if</span> (<span class="s4">self</span>.oclAsType(<span class="s5">ECORE</span>::<span class="s5">EObject</span>).eIsSet(<span class="s4">self</span>.oclAsType(<span class="s5">ECORE</span>::<span class="s5">EObject</span>).eClass().getEStructuralFeature(feature))) <span class="s1">then</span>{</p>
<p class="p5"><span class="Apple-tab-span"> </span><span class="Apple-tab-span"> </span>value := <span class="s1">true</span>;</p>
<p class="p6"><span class="s2"><span class="Apple-tab-span"> </span>}</span>endif<span class="s2">;</span></p>
<p class="p5"><span class="Apple-tab-span"> </span><span class="s1">return</span> value;</p>
<p class="p5">}</p>
<p class="p2"><br></p>
<p class="p1">I can then call this from within the code as something like:</p>
<p class="p2"><br></p>
<p class="p7"><span class="s1">if</span><span class="s2"> (</span><span class="s4">self</span><span class="s2">.</span><span class="s3">isSet</span><span class="s2">(</span><span class="s6">"pTolerance"</span><span class="s2">)) </span><span class="s1">then</span><span class="s2">{ </span><span class="s4">result</span><span class="s2">.</span>tolerance<span class="s2"> := </span><span class="s4">self</span><span class="s2">.</span>pTolerance<span class="s2">;}</span><span class="s1">endif</span><span class="s2">;</span></p>
<p class="p8"><br></p>
<p class="p1">Obviously the main problem here is that you're referring to the attribute as a string so there's the risk you mistype it and you won't get auto-correction, but I only use it for the primitive types where the default vs unset case is required. This was a simpler approach than trying to modify the underlying QVT engine</p>
<p class="p2"><br></p>
<p class="p1">Alan</p>
<p class="p2"><br></p>
<p class="p2"><br></p>
<p class="p2"><br></p>
<p class="p1">On 2013-01-18 13:39:09 +0000, Marius Gröger said:</p>
<p class="p2"><br></p>
<p class="p9">On 18.01.2013 14:00, Ed Willink wrote:</p>
<p class="p10">Surely you can control unset on the output by wrapping the assignment in</p>
<p class="p10">an imperative if? Then you just need a helper function to allow you to</p>
<p class="p10">test whether a source value is unset.</p>
<p class="p11"><br></p>
<p class="p12">Meaning to analyse the source as an EObject and checking eIsSet()?</p>
<p class="p12">Probably, but it would really mess up the QVT code a lot. And I really</p>
<p class="p12">only see this issue with primitive floats.</p>
<p class="p11"><br></p>
<p class="p12">I just posted a work-around on e.t.emf in the thread 'Annoying intrinsic</p>
<p class="p12">default values for primitive types'. That solution concerns XSD models.</p>
<p class="p12">Regular Ecore models won't be affected by this as long as all values are</p>
<p class="p12">put into custom EDataTypes, ie. if EInt, EFloat etc are avoided.</p>
<p class="p11"><br></p>
<p class="p12">Regards</p>
<p class="p12">Marius</p>
<p class="p13"><br></p>
</body>
</html>
Re: Unsettable attribute, intrinsic defaults [message #1002438 is a reply to message #1002426] Fri, 18 January 2013 15:19 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
It should be possible for OCL to provide an
OclElement::oclIsSet(Property) method that might then allow<br>
<br>
<p class="p7"><span class="s1">if</span><span class="s2"> (</span><span
class="s4">self</span><span class="s2">.</span><span class="s3">oclsSet</span><span
class="s2">(</span><span class="s6">pTolerance</span><span
class="s2">)) </span><span class="s1">then</span><span
class="s2">{ </span><span class="s4">result</span><span
class="s2">.</span>tolerance<span class="s2"> := </span><span
class="s4">self</span><span class="s2">.</span>pTolerance<span
class="s2">;}</span><span class="s1">endif</span><span
class="s2">;</span></p>
<br>
but there might be a syntax ambiguity requiring<br>
<br>
<p class="p7"><span class="s1">if</span><span class="s2"> (</span><span
class="s4">self</span><span class="s2">.</span><span class="s3">oclsSet</span><span
class="s2">(MyClass::</span><span class="s6">pTolerance</span><span
class="s2">)) </span><span class="s1">then</span><span
class="s2">{ </span><span class="s4">result</span><span
class="s2">.</span>tolerance<span class="s2"> := </span><span
class="s4">self</span><span class="s2">.</span>pTolerance<span
class="s2">;}</span><span class="s1">endif</span><span
class="s2">;</span></p>
<br>
&nbsp;&nbsp;&nbsp; Regards<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed Willink<br>
<br>
<br>
<br>
On 18/01/2013 14:55, Alan McMorran wrote:
<blockquote cite="mid:kdbnor$lfd$1@xxxxxxxxe.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1138.51">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #3344fc}
p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #921e67; min-height: 15.0px}
p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p6 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #921e67}
p.p7 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #0034c9}
p.p8 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p9 {margin: 0.0px 0.0px 0.0px 12.0px; line-height: 14.0px; font: 12.0px Helvetica; color: #002390}
p.p10 {margin: 0.0px 0.0px 0.0px 24.0px; font: 12.0px Helvetica; color: #008d12}
p.p11 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390; min-height: 14.0px}
p.p12 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390}
p.p13 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #000000; min-height: 14.0px}
span.s1 {color: #921e67}
span.s2 {color: #000000}
span.s3 {color: #83195c}
span.s4 {color: #002cae}
span.s5 {color: #0034c9}
span.s6 {color: #3344fc}
span.Apple-tab-span {white-space:pre}
</style>
<p class="p1">I ran into this problem and my solution is to sort
of cheat a bit and add a Helper method:</p>
<p class="p2"><br>
</p>
<p class="p3"><span class="s1">modeltype</span><span class="s2">
ECORE </span><span class="s1">uses</span><span class="s2"> </span>'<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore">http://www.eclipse.org/emf/2002/Ecore</a>'<span
class="s2">;</span></p>
<p class="p4"><br>
</p>
<p class="p5"><span class="s1">helper</span> OclAny::<span
class="s3">isSet</span>(feature : String) : Boolean{</p>
<p class="p5"><span class="Apple-tab-span"> </span><span
class="s1">var</span> value : Boolean := <span class="s1">false</span>;</p>
<p class="p5"><span class="Apple-tab-span"> </span><span
class="s1">if</span> (<span class="s4">self</span>.oclAsType(<span
class="s5">ECORE</span>::<span class="s5">EObject</span>).eIsSet(<span
class="s4">self</span>.oclAsType(<span class="s5">ECORE</span>::<span
class="s5">EObject</span>).eClass().getEStructuralFeature(feature)))
<span class="s1">then</span>{</p>
<p class="p5"><span class="Apple-tab-span"> </span><span
class="Apple-tab-span"> </span>value := <span class="s1">true</span>;</p>
<p class="p6"><span class="s2"><span class="Apple-tab-span"> </span>}</span>endif<span
class="s2">;</span></p>
<p class="p5"><span class="Apple-tab-span"> </span><span
class="s1">return</span> value;</p>
<p class="p5">}</p>
<p class="p2"><br>
</p>
<p class="p1">I can then call this from within the code as
something like:</p>
<p class="p2"><br>
</p>
<p class="p7"><span class="s1">if</span><span class="s2"> (</span><span
class="s4">self</span><span class="s2">.</span><span
class="s3">isSet</span><span class="s2">(</span><span
class="s6">"pTolerance"</span><span class="s2">)) </span><span
class="s1">then</span><span class="s2">{ </span><span
class="s4">result</span><span class="s2">.</span>tolerance<span
class="s2"> := </span><span class="s4">self</span><span
class="s2">.</span>pTolerance<span class="s2">;}</span><span
class="s1">endif</span><span class="s2">;</span></p>
<p class="p8"><br>
</p>
<p class="p1">Obviously the main problem here is that you're
referring to the attribute as a string so there's the risk you
mistype it and you won't get auto-correction, but I only use it
for the primitive types where the default vs unset case is
required. This was a simpler approach than trying to modify the
underlying QVT engine</p>
<p class="p2"><br>
</p>
<p class="p1">Alan</p>
<p class="p2"><br>
</p>
<p class="p2"><br>
</p>
<p class="p2"><br>
</p>
<p class="p1">On 2013-01-18 13:39:09 +0000, Marius Gr&ouml;ger said:</p>
<p class="p2"><br>
</p>
<p class="p9">On 18.01.2013 14:00, Ed Willink wrote:</p>
<p class="p10">Surely you can control unset on the output by
wrapping the assignment in</p>
<p class="p10">an imperative if? Then you just need a helper
function to allow you to</p>
<p class="p10">test whether a source value is unset.</p>
<p class="p11"><br>
</p>
<p class="p12">Meaning to analyse the source as an EObject and
checking eIsSet()?</p>
<p class="p12">Probably, but it would really mess up the QVT code
a lot. And I really</p>
<p class="p12">only see this issue with primitive floats.</p>
<p class="p11"><br>
</p>
<p class="p12">I just posted a work-around on e.t.emf in the
thread 'Annoying intrinsic</p>
<p class="p12">default values for primitive types'. That solution
concerns XSD models.</p>
<p class="p12">Regular Ecore models won't be affected by this as
long as all values are</p>
<p class="p12">put into custom EDataTypes, ie. if EInt, EFloat etc
are avoided.</p>
<p class="p11"><br>
</p>
<p class="p12">Regards</p>
<p class="p12">Marius</p>
<p class="p13"><br>
</p>
</blockquote>
<br>
</body>
</html>
Re: Unsettable attribute, intrinsic defaults [message #1002523 is a reply to message #1002438] Fri, 18 January 2013 19:01 Go to previous messageGo to next message
Alan McMorran is currently offline Alan McMorranFriend
Messages: 55
Registered: July 2009
Member
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1138.51">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p4 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Helvetica; color: #002390}
p.p5 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Helvetica; color: #002390; min-height: 19.0px}
p.p6 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390}
p.p7 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390; min-height: 14.0px}
p.p8 {margin: 0.0px 0.0px 0.0px 24.0px; font: 12.0px Helvetica; color: #008d12}
p.p9 {margin: 0.0px 0.0px 0.0px 36.0px; font: 12.0px Helvetica; color: #930f04}
p.p10 {margin: 0.0px 0.0px 0.0px 24.0px; font: 12.0px Helvetica; color: #008d12; min-height: 14.0px}
p.p11 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica; min-height: 14.0px}
span.s1 {color: #921e67}
span.s2 {color: #83195c}
span.s3 {text-decoration: underline}
span.Apple-tab-span {white-space:pre}
</style>
</head>
<body>
<p class="p1">Ed,</p>
<p class="p2"><br></p>
<p class="p1">That would be nice, right now the problem I get if I try to reference MyClass::pTolerance in QVT is that it complains about:</p>
<p class="p1"><span class="Apple-tab-span"> </span>'static reference to non-static attribute "pTolerance"'</p>
<p class="p2"><br></p>
<p class="p1">So even doing a method of:</p>
<p class="p3"><span class="s1"><span class="Apple-tab-span"> </span>helper</span> OclAny::<span class="s2">isSetOcl</span>(feature : OclAny) : Boolean{</p>
<p class="p2"><br></p>
<p class="p1">Would not work as we can't reference the property in the QVT code in the first place.</p>
<p class="p2"><br></p>
<p class="p1">As I said, the string passing method isn't the cleanest but it works and the implementation below doesn't even require a black-box :-)</p>
<p class="p2"><br></p>
<p class="p1">Alan</p>
<p class="p2"><br></p>
<p class="p2"><br></p>
<p class="p1">On 2013-01-18 15:19:21 +0000, Ed Willink said:</p>
<p class="p2"><br></p>
<p class="p4">Hi</p>
<p class="p5"><br></p>
<p class="p4">It should be possible for OCL to provide an OclElement::oclIsSet(Property) method that might then allow</p>
<p class="p5"><br></p>
<p class="p6">if (self.oclsSet(pTolerance)) then{ result.tolerance := self.pTolerance;}endif;</p>
<p class="p5"><br></p>
<p class="p4">but there might be a syntax ambiguity requiring</p>
<p class="p5"><br></p>
<p class="p6">if (self.oclsSet(MyClass::pTolerance)) then{ result.tolerance := self.pTolerance;}endif;</p>
<p class="p5"><br></p>
<p class="p4">    Regards</p>
<p class="p5"><br></p>
<p class="p4">        Ed Willink</p>
<p class="p5"><br></p>
<p class="p5"><br></p>
<p class="p5"><br></p>
<p class="p4">On 18/01/2013 14:55, Alan McMorran wrote:</p>
<p class="p6">I ran into this problem and my solution is to sort of cheat a bit and add a Helper method:</p>
<p class="p7"><br></p>
<p class="p6">modeltype ECORE uses '<a href="http://www.eclipse.org/emf/2002/Ecore"><span class="s3">http://www.eclipse.org/emf/2002/Ecore</span></a>';</p>
<p class="p7"><br></p>
<p class="p6">helper OclAny::isSet(feature : String) : Boolean{</p>
<p class="p6"><span class="Apple-converted-space"> </span>var value : Boolean := false;</p>
<p class="p6"><span class="Apple-converted-space"> </span>if (self.oclAsType(ECORE::EObject).eIsSet(self.oclAsType(ECORE::EObject).eClass().getEStructuralFeature(feature))) then{</p>
<p class="p6"><span class="Apple-converted-space">  </span>value := true;</p>
<p class="p6"><span class="Apple-converted-space"> </span>}endif;</p>
<p class="p6"><span class="Apple-converted-space"> </span>return value;</p>
<p class="p6">}</p>
<p class="p7"><br></p>
<p class="p6">I can then call this from within the code as something like:</p>
<p class="p7"><br></p>
<p class="p6">if (self.isSet("pTolerance")) then{ result.tolerance := self.pTolerance;}endif;</p>
<p class="p7"><br></p>
<p class="p6">Obviously the main problem here is that you're referring to the attribute as a string so there's the risk you mistype it and you won't get auto-correction, but I only use it for the primitive types where the default vs unset case is required. This was a simpler approach than trying to modify the underlying QVT engine</p>
<p class="p7"><br></p>
<p class="p6">Alan</p>
<p class="p7"><br></p>
<p class="p7"><br></p>
<p class="p7"><br></p>
<p class="p6">On 2013-01-18 13:39:09 +0000, Marius Gröger said:</p>
<p class="p7"><br></p>
<p class="p8">On 18.01.2013 14:00, Ed Willink wrote:</p>
<p class="p9">Surely you can control unset on the output by wrapping the assignment in</p>
<p class="p9">an imperative if? Then you just need a helper function to allow you to</p>
<p class="p9">test whether a source value is unset.</p>
<p class="p10"><br></p>
<p class="p8">Meaning to analyse the source as an EObject and checking eIsSet()?</p>
<p class="p8">Probably, but it would really mess up the QVT code a lot. And I really</p>
<p class="p8">only see this issue with primitive floats.</p>
<p class="p10"><br></p>
<p class="p8">I just posted a work-around on e.t.emf in the thread 'Annoying intrinsic</p>
<p class="p8">default values for primitive types'. That solution concerns XSD models.</p>
<p class="p8">Regular Ecore models won't be affected by this as long as all values are</p>
<p class="p8">put into custom EDataTypes, ie. if EInt, EFloat etc are avoided.</p>
<p class="p10"><br></p>
<p class="p8">Regards</p>
<p class="p8">Marius</p>
<p class="p11"><br></p>
</body>
</html>
Re: Unsettable attribute, intrinsic defaults [message #1002529 is a reply to message #1002523] Fri, 18 January 2013 19:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Alan<br>
<br>
That's why oclIsSet(pTolerance) might not work; is 'pTolerance' a
VariableExp or a PropertyLiteralExp?<br>
<br>
oclIsSet(MyClass::pTolerance) might be more tractably a
PropertyLiteralExp?<br>
<br>
NB. OCL's support for Element Literals is patchy at present; types
for oclAsType and expressions for iterator bodies.<br>
<br>
I have yet to decide quite what form of ElementLiteralExp
could/should be added.<br>
<br>
&nbsp;&nbsp;&nbsp; Regards<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed Willink<br>
<br>
On 18/01/2013 19:01, Alan McMorran wrote:
<blockquote cite="mid:kdc666$i0e$1@xxxxxxxxe.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1138.51">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p4 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Helvetica; color: #002390}
p.p5 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Helvetica; color: #002390; min-height: 19.0px}
p.p6 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390}
p.p7 {margin: 0.0px 0.0px 0.0px 12.0px; font: 12.0px Helvetica; color: #002390; min-height: 14.0px}
p.p8 {margin: 0.0px 0.0px 0.0px 24.0px; font: 12.0px Helvetica; color: #008d12}
p.p9 {margin: 0.0px 0.0px 0.0px 36.0px; font: 12.0px Helvetica; color: #930f04}
p.p10 {margin: 0.0px 0.0px 0.0px 24.0px; font: 12.0px Helvetica; color: #008d12; min-height: 14.0px}
p.p11 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica; min-height: 14.0px}
span.s1 {color: #921e67}
span.s2 {color: #83195c}
span.s3 {text-decoration: underline}
span.Apple-tab-span {white-space:pre}
</style>
<p class="p1">Ed,</p>
<p class="p2"><br>
</p>
<p class="p1">That would be nice, right now the problem I get if I
try to reference MyClass::pTolerance in QVT is that it complains
about:</p>
<p class="p1"><span class="Apple-tab-span"> </span>'static
reference to non-static attribute "pTolerance"'</p>
<p class="p2"><br>
</p>
<p class="p1">So even doing a method of:</p>
<p class="p3"><span class="s1"><span class="Apple-tab-span"> </span>helper</span>
OclAny::<span class="s2">isSetOcl</span>(feature : OclAny) :
Boolean{</p>
<p class="p2"><br>
</p>
<p class="p1">Would not work as we can't reference the property in
the QVT code in the first place.</p>
<p class="p2"><br>
</p>
<p class="p1">As I said, the string passing method isn't the
cleanest but it works and the implementation below doesn't even
require a black-box :-)</p>
<p class="p2"><br>
</p>
<p class="p1">Alan</p>
<p class="p2"><br>
</p>
<p class="p2"><br>
</p>
<p class="p1">On 2013-01-18 15:19:21 +0000, Ed Willink said:</p>
<p class="p2"><br>
</p>
<p class="p4">Hi</p>
<p class="p5"><br>
</p>
<p class="p4">It should be possible for OCL to provide an
OclElement::oclIsSet(Property) method that might then allow</p>
<p class="p5"><br>
</p>
<p class="p6">if (self.oclsSet(pTolerance)) then{ result.tolerance
:= self.pTolerance;}endif;</p>
<p class="p5"><br>
</p>
<p class="p4">but there might be a syntax ambiguity requiring</p>
<p class="p5"><br>
</p>
<p class="p6">if (self.oclsSet(MyClass::pTolerance)) then{
result.tolerance := self.pTolerance;}endif;</p>
<p class="p5"><br>
</p>
<p class="p4">&nbsp;&nbsp;&nbsp; Regards</p>
<p class="p5"><br>
</p>
<p class="p4">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed Willink</p>
<p class="p5"><br>
</p>
<p class="p5"><br>
</p>
<p class="p5"><br>
</p>
<p class="p4">On 18/01/2013 14:55, Alan McMorran wrote:</p>
<p class="p6">I ran into this problem and my solution is to sort
of cheat a bit and add a Helper method:</p>
<p class="p7"><br>
</p>
<p class="p6">modeltype ECORE uses '<a moz-do-not-send="true"
href="http://www.eclipse.org/emf/2002/Ecore"><span class="s3">http://www.eclipse.org/emf/2002/Ecore</span></a>';</p>
<p class="p7"><br>
</p>
<p class="p6">helper OclAny::isSet(feature : String) : Boolean{</p>
<p class="p6"><span class="Apple-converted-space">&nbsp;</span>var
value : Boolean := false;</p>
<p class="p6"><span class="Apple-converted-space">&nbsp;</span>if
(self.oclAsType(ECORE::EObject).eIsSet(self.oclAsType(ECORE::EObject).eClass().getEStructuralFeature(feature)))
then{</p>
<p class="p6"><span class="Apple-converted-space">&nbsp; </span>value
:= true;</p>
<p class="p6"><span class="Apple-converted-space">&nbsp;</span>}endif;</p>
<p class="p6"><span class="Apple-converted-space">&nbsp;</span>return
value;</p>
<p class="p6">}</p>
<p class="p7"><br>
</p>
<p class="p6">I can then call this from within the code as
something like:</p>
<p class="p7"><br>
</p>
<p class="p6">if (self.isSet("pTolerance")) then{ result.tolerance
:= self.pTolerance;}endif;</p>
<p class="p7"><br>
</p>
<p class="p6">Obviously the main problem here is that you're
referring to the attribute as a string so there's the risk you
mistype it and you won't get auto-correction, but I only use it
for the primitive types where the default vs unset case is
required. This was a simpler approach than trying to modify the
underlying QVT engine</p>
<p class="p7"><br>
</p>
<p class="p6">Alan</p>
<p class="p7"><br>
</p>
<p class="p7"><br>
</p>
<p class="p7"><br>
</p>
<p class="p6">On 2013-01-18 13:39:09 +0000, Marius Gr&ouml;ger said:</p>
<p class="p7"><br>
</p>
<p class="p8">On 18.01.2013 14:00, Ed Willink wrote:</p>
<p class="p9">Surely you can control unset on the output by
wrapping the assignment in</p>
<p class="p9">an imperative if? Then you just need a helper
function to allow you to</p>
<p class="p9">test whether a source value is unset.</p>
<p class="p10"><br>
</p>
<p class="p8">Meaning to analyse the source as an EObject and
checking eIsSet()?</p>
<p class="p8">Probably, but it would really mess up the QVT code a
lot. And I really</p>
<p class="p8">only see this issue with primitive floats.</p>
<p class="p10"><br>
</p>
<p class="p8">I just posted a work-around on e.t.emf in the thread
'Annoying intrinsic</p>
<p class="p8">default values for primitive types'. That solution
concerns XSD models.</p>
<p class="p8">Regular Ecore models won't be affected by this as
long as all values are</p>
<p class="p8">put into custom EDataTypes, ie. if EInt, EFloat etc
are avoided.</p>
<p class="p10"><br>
</p>
<p class="p8">Regards</p>
<p class="p8">Marius</p>
<p class="p11"><br>
</p>
</blockquote>
<br>
</body>
</html>
Re: Unsettable attribute, intrinsic defaults [message #1003937 is a reply to message #1002426] Tue, 22 January 2013 09:25 Go to previous messageGo to next message
Eclipse UserFriend
Alan,

On 18.01.2013 15:55, Alan McMorran wrote:
> I ran into this problem and my solution is to sort of cheat a bit and
> add a Helper method:

Thanks for sharing this. TBH, I was aware that this can be solved like
this, but I don't really like having to actively remember writing that
if-isSet-then-set-endif clause everytime I assign such a value. What's
more, we are working on those transformations in a team so everybody has
to remember.

To recap: if you use custom datatypes in your EMF models that point to
java.lang.Float etc., then attributes with these types can very well be
unset and will deliver "null" when QVT calls eGet(). No problem here,
because when QVT subsequently eSet()s this "null" value to the output
variable, everything behaves as expected.

It's _only_ primitive types (EFloat etc. and --in my case-- xs:float
from an originating XSD) which will magically deliver the intrinsic
default even when they were never explicitly assigned. While I
understand Ed Merck's argument that intrinsic values just always have a
default, I like my models to be truely unsettable and returning "null"
if so.

Over in http://www.eclipse.org/forums/index.php/m/1002492/ I shared how
I now import my XML instances by enforcing xs:float to be mapped to Float.

Regards
Marius
Re: Unsettable attribute, intrinsic defaults [message #1004032 is a reply to message #1003937] Tue, 22 January 2013 13:29 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 260
Registered: July 2009
Senior Member
On 22/01/2013 09:25, Marius Gröger wrote:
> To recap: if you use custom datatypes in your EMF models that point to
> java.lang.Float etc.

Hi Marius,

Remember that apart from the Ecore EDataTypes for java primitive types
(EFloat, EInt, ...) you also have Ecore EDataTypes counterparts for true
java Objects: EFloatObject, EIntegerObject, ... so, if desired, you
don't need to create custom datatypes at all.

Cheers,
Adolfo.
Re: Unsettable attribute, intrinsic defaults [message #1004085 is a reply to message #1004032] Tue, 22 January 2013 14:49 Go to previous message
Eclipse UserFriend
On 22.01.2013 14:29, Adolfo Sánchez-Barbudo Herrera wrote:
> On 22/01/2013 09:25, Marius Gröger wrote:
>> To recap: if you use custom datatypes in your EMF models that point to
>> java.lang.Float etc.
>
> Hi Marius,
>
> Remember that apart from the Ecore EDataTypes for java primitive types
> (EFloat, EInt, ...) you also have Ecore EDataTypes counterparts for true
> java Objects: EFloatObject, EIntegerObject, ... so, if desired, you
> don't need to create custom datatypes at all.

Thanks for this hint, I was indeed not really aware of this. In our
project however we need custom datatypes anyway because we add a number
of custom annotations that further refine allowed content.

Regards
Marius
Previous Topic:Errors running builder 'QVT Operational Builder'
Next Topic:Constant rebuilds
Goto Forum:
  


Current Time: Fri Mar 29 15:40:04 GMT 2024

Powered by FUDForum. Page generated in 0.06021 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top