Home » Modeling » OCL » Operations on ELong
Operations on ELong [message #34859] |
Tue, 31 July 2007 17:13 |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
I have a model with a class called Tag and within this class an
attribute with an ELong type called idNumber.
In the generated model Editor using the OCL Interpreter with the Tag
class as context I can do:
Evaluating:
idNumber
Results:
1234
Would eventually like to put a constraint on this attribute to keep it
below a certain size. So I've tried unsuccessfully to do a less than on
it like:
Evaluating:
idNumber <10000
Results:
Invalid Class
?? So I tried:
Evaluating:
1<2
Results:
true
Which works as expected. Perhaps I am confused about OCL syntax and I
am not specifying this correctly? Any ideas or pointers about how I
should specify this?
thanks,
John
|
|
|
Re: Operations on ELong [message #34902 is a reply to message #34859] |
Tue, 31 July 2007 17:31 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, John,
I suspect that this is a bug in the OCL interpreter. Probably the run-time
value of the ELong attribute is java.lang.Long, but OCL doesn't have a
"long" data type and thus expects this to be an Integer, resulting in a
ClassCastException, which is manifest as OclInvalid.
If you can get a stack trace to confirm, please raise a bug.
Thanks!
Christian
John E. Conlon wrote:
> I have a model with a class called Tag and within this class an
> attribute with an ELong type called idNumber.
>
> In the generated model Editor using the OCL Interpreter with the Tag
> class as context I can do:
>
> Evaluating:
> idNumber
>
> Results:
> 1234
>
>
>
> Would eventually like to put a constraint on this attribute to keep it
> below a certain size. So I've tried unsuccessfully to do a less than on
> it like:
>
> Evaluating:
> idNumber <10000
>
> Results:
> Invalid Class
>
> ?? So I tried:
>
> Evaluating:
> 1<2
>
> Results:
> true
>
> Which works as expected. Perhaps I am confused about OCL syntax and I
> am not specifying this correctly? Any ideas or pointers about how I
> should specify this?
>
> thanks,
> John
|
|
|
Re: Operations on ELong [message #34926 is a reply to message #34902] |
Tue, 31 July 2007 20:18 |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Christian,
Your right. So I created bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=198451
cheers,
John
Christian W. Damus wrote:
> Hi, John,
>
> I suspect that this is a bug in the OCL interpreter. Probably the run-time
> value of the ELong attribute is java.lang.Long, but OCL doesn't have a
> "long" data type and thus expects this to be an Integer, resulting in a
> ClassCastException, which is manifest as OclInvalid.
>
> If you can get a stack trace to confirm, please raise a bug.
>
> Thanks!
>
> Christian
>
>
> John E. Conlon wrote:
>
>> I have a model with a class called Tag and within this class an
>> attribute with an ELong type called idNumber.
>>
>> In the generated model Editor using the OCL Interpreter with the Tag
>> class as context I can do:
>>
>> Evaluating:
>> idNumber
>>
>> Results:
>> 1234
>>
>>
>>
>> Would eventually like to put a constraint on this attribute to keep it
>> below a certain size. So I've tried unsuccessfully to do a less than on
>> it like:
>>
>> Evaluating:
>> idNumber <10000
>>
>> Results:
>> Invalid Class
>>
>> ?? So I tried:
>>
>> Evaluating:
>> 1<2
>>
>> Results:
>> true
>>
>> Which works as expected. Perhaps I am confused about OCL syntax and I
>> am not specifying this correctly? Any ideas or pointers about how I
>> should specify this?
>>
>> thanks,
>> John
>
|
|
|
Re: Operations on ELong [message #36634 is a reply to message #34926] |
Tue, 11 September 2007 11:21 |
Andreas Werner Messages: 55 Registered: July 2009 |
Member |
|
|
Hello,
there's still another relating bug open:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=164795
Andreas
> Hi Christian,
>
> Your right. So I created bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198451
> cheers,
> John
> Christian W. Damus wrote:
>
>> Hi, John,
>>
>> I suspect that this is a bug in the OCL interpreter. Probably the
>> run-time value of the ELong attribute is java.lang.Long, but OCL
>> doesn't have a "long" data type and thus expects this to be an
>> Integer, resulting in a ClassCastException, which is manifest as
>> OclInvalid.
>>
>> If you can get a stack trace to confirm, please raise a bug.
>>
>> Thanks!
>>
>> Christian
>>
>> John E. Conlon wrote:
>>
>>> I have a model with a class called Tag and within this class an
>>> attribute with an ELong type called idNumber.
>>>
>>> In the generated model Editor using the OCL Interpreter with the Tag
>>> class as context I can do:
>>>
>>> Evaluating:
>>> idNumber
>>> Results:
>>> 1234
>>> Would eventually like to put a constraint on this attribute to keep
>>> it below a certain size. So I've tried unsuccessfully to do a less
>>> than on it like:
>>>
>>> Evaluating:
>>> idNumber <10000
>>> Results:
>>> Invalid Class
>>> ?? So I tried:
>>>
>>> Evaluating:
>>> 1<2
>>> Results:
>>> true
>>> Which works as expected. Perhaps I am confused about OCL syntax and
>>> I am not specifying this correctly? Any ideas or pointers about how
>>> I should specify this?
>>>
>>> thanks,
>>> John
|
|
|
Re: Operations on ELong [message #36769 is a reply to message #36634] |
Tue, 11 September 2007 20:32 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andreas,
It will require some thought to figure out how to reconcile EMF's ELong with
OCL which only recognizes a single Integer type. If you can contribute a
patch that resolves the conundrum while maintaining compatibility, I will
be more than happy to process it!
Cheers,
Christian
Andreas Werner wrote:
> Hello,
>
> there's still another relating bug open:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=164795
>
> Andreas
>
>> Hi Christian,
>>
>> Your right. So I created bug:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198451
>> cheers,
>> John
>> Christian W. Damus wrote:
>>
>>> Hi, John,
>>>
>>> I suspect that this is a bug in the OCL interpreter. Probably the
>>> run-time value of the ELong attribute is java.lang.Long, but OCL
>>> doesn't have a "long" data type and thus expects this to be an
>>> Integer, resulting in a ClassCastException, which is manifest as
>>> OclInvalid.
>>>
>>> If you can get a stack trace to confirm, please raise a bug.
>>>
>>> Thanks!
>>>
>>> Christian
>>>
>>> John E. Conlon wrote:
>>>
>>>> I have a model with a class called Tag and within this class an
>>>> attribute with an ELong type called idNumber.
>>>>
>>>> In the generated model Editor using the OCL Interpreter with the Tag
>>>> class as context I can do:
>>>>
>>>> Evaluating:
>>>> idNumber
>>>> Results:
>>>> 1234
>>>> Would eventually like to put a constraint on this attribute to keep
>>>> it below a certain size. So I've tried unsuccessfully to do a less
>>>> than on it like:
>>>>
>>>> Evaluating:
>>>> idNumber <10000
>>>> Results:
>>>> Invalid Class
>>>> ?? So I tried:
>>>>
>>>> Evaluating:
>>>> 1<2
>>>> Results:
>>>> true
>>>> Which works as expected. Perhaps I am confused about OCL syntax and
>>>> I am not specifying this correctly? Any ideas or pointers about how
>>>> I should specify this?
>>>>
>>>> thanks,
>>>> John
|
|
|
Re: Operations on ELong [message #37139 is a reply to message #36769] |
Fri, 14 September 2007 13:10 |
Andreas Werner Messages: 55 Registered: July 2009 |
Member |
|
|
Hello Christian,
in my opinion the solution is to use java.lang.Long for OCL's type Integer
within the implementation! I cannot believe, that OMG says java.lang.Integer
must be used. Or, why did the Eclipse.OCL team decide to take java.lang.Integer
instead of Long?
The same holds for java.lang.Double and OCL's Real.
What do you think about this? Or did I misunderstand the problem?
Andreas
> Hi, Andreas,
>
> It will require some thought to figure out how to reconcile EMF's
> ELong with
> OCL which only recognizes a single Integer type. If you can
> contribute a
> patch that resolves the conundrum while maintaining compatibility, I
> will
> be more than happy to process it!
> Cheers,
>
> Christian
>
> Andreas Werner wrote:
>
>> Hello,
>>
>> there's still another relating bug open:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=164795
>> Andreas
>>
>>> Hi Christian,
>>>
>>> Your right. So I created bug:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198451
>>> cheers,
>>> John
>>> Christian W. Damus wrote:
>>>> Hi, John,
>>>>
>>>> I suspect that this is a bug in the OCL interpreter. Probably the
>>>> run-time value of the ELong attribute is java.lang.Long, but OCL
>>>> doesn't have a "long" data type and thus expects this to be an
>>>> Integer, resulting in a ClassCastException, which is manifest as
>>>> OclInvalid.
>>>>
>>>> If you can get a stack trace to confirm, please raise a bug.
>>>>
>>>> Thanks!
>>>>
>>>> Christian
>>>>
>>>> John E. Conlon wrote:
>>>>
>>>>> I have a model with a class called Tag and within this class an
>>>>> attribute with an ELong type called idNumber.
>>>>>
>>>>> In the generated model Editor using the OCL Interpreter with the
>>>>> Tag class as context I can do:
>>>>>
>>>>> Evaluating:
>>>>> idNumber
>>>>> Results:
>>>>> 1234
>>>>> Would eventually like to put a constraint on this attribute to
>>>>> keep
>>>>> it below a certain size. So I've tried unsuccessfully to do a
>>>>> less
>>>>> than on it like:
>>>>> Evaluating:
>>>>> idNumber <10000
>>>>> Results:
>>>>> Invalid Class
>>>>> ?? So I tried:
>>>>> Evaluating:
>>>>> 1<2
>>>>> Results:
>>>>> true
>>>>> Which works as expected. Perhaps I am confused about OCL syntax
>>>>> and
>>>>> I am not specifying this correctly? Any ideas or pointers about
>>>>> how
>>>>> I should specify this?
>>>>> thanks,
>>>>> John
|
|
|
Re: Operations on ELong [message #37173 is a reply to message #37139] |
Fri, 14 September 2007 13:57 |
Andreas Werner Messages: 55 Registered: July 2009 |
Member |
|
|
Oh, I've seen now, that Double values are yet supported!!!
> Hello Christian,
>
> in my opinion the solution is to use java.lang.Long for OCL's type
> Integer within the implementation! I cannot believe, that OMG says
> java.lang.Integer must be used. Or, why did the Eclipse.OCL team
> decide to take java.lang.Integer instead of Long?
>
> The same holds for java.lang.Double and OCL's Real.
>
> What do you think about this? Or did I misunderstand the problem?
>
> Andreas
>
>> Hi, Andreas,
>>
>> It will require some thought to figure out how to reconcile EMF's
>> ELong with
>> OCL which only recognizes a single Integer type. If you can
>> contribute a
>> patch that resolves the conundrum while maintaining compatibility, I
>> will
>> be more than happy to process it!
>> Cheers,
>> Christian
>>
>> Andreas Werner wrote:
>>
>>> Hello,
>>>
>>> there's still another relating bug open:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=164795 Andreas
>>>
>>>> Hi Christian,
>>>>
>>>> Your right. So I created bug:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198451
>>>> cheers,
>>>> John
>>>> Christian W. Damus wrote:
>>>>> Hi, John,
>>>>>
>>>>> I suspect that this is a bug in the OCL interpreter. Probably the
>>>>> run-time value of the ELong attribute is java.lang.Long, but OCL
>>>>> doesn't have a "long" data type and thus expects this to be an
>>>>> Integer, resulting in a ClassCastException, which is manifest as
>>>>> OclInvalid.
>>>>>
>>>>> If you can get a stack trace to confirm, please raise a bug.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Christian
>>>>>
>>>>> John E. Conlon wrote:
>>>>>
>>>>>> I have a model with a class called Tag and within this class an
>>>>>> attribute with an ELong type called idNumber.
>>>>>>
>>>>>> In the generated model Editor using the OCL Interpreter with the
>>>>>> Tag class as context I can do:
>>>>>>
>>>>>> Evaluating:
>>>>>> idNumber
>>>>>> Results:
>>>>>> 1234
>>>>>> Would eventually like to put a constraint on this attribute to
>>>>>> keep
>>>>>> it below a certain size. So I've tried unsuccessfully to do a
>>>>>> less
>>>>>> than on it like:
>>>>>> Evaluating:
>>>>>> idNumber <10000
>>>>>> Results:
>>>>>> Invalid Class
>>>>>> ?? So I tried:
>>>>>> Evaluating:
>>>>>> 1<2
>>>>>> Results:
>>>>>> true
>>>>>> Which works as expected. Perhaps I am confused about OCL syntax
>>>>>> and
>>>>>> I am not specifying this correctly? Any ideas or pointers about
>>>>>> how
>>>>>> I should specify this?
>>>>>> thanks,
>>>>>> John
|
|
|
Re: Operations on ELong [message #37207 is a reply to message #37139] |
Fri, 14 September 2007 14:05 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andreas,
Of course, the OMG is only concerned with the mathematical notions of
integer, natural, and real numbers, which are not constrained by the
precision of a binary representation.
It isn't as easy as just changing to use java.lang.Long for integer values
because that would be an API-breaking change. And why java.lang.Long? Why
not BigInteger for infinite precision?
There wasn't any specific decision to use java.lang.Integer that I know of.
The problem, now, is how to deal with the fact that some Ecore models will
supply Long values that we have to be able to accommodate. That requires
more time than I can afford just now, which is why solutions/patches that
resolve the problem without breaking compatibility are most welcome. It's
not that I don't think it's an important problem to solve, but it just
isn't a priority for me and my employer at this time.
One avenue to pursue would be to enhance the EvaluationVisitor
implementation to automatically cast numbers to Long during the evaluation
9for maximal arithmetic precision), and convert them to Integer before
returning them to clients whenever possible. In this way, existing clients
still get Integers because they could only have been using Integers before,
anyway (else, failing with run-time exceptions because their values
overflow). Future clients can rely on the abstract Number API to get long
values for any number if they choose, or be more adaptable to whether they
see Integer or Long results. This would also have to account for coercing
Longs to Integers when passing them as arguments to user-defined
operations, etc.
Is that something you might like to work on?
Cheers,
Christian
Andreas Werner wrote:
> Hello Christian,
>
> in my opinion the solution is to use java.lang.Long for OCL's type Integer
> within the implementation! I cannot believe, that OMG says
> java.lang.Integer must be used. Or, why did the Eclipse.OCL team decide to
> take java.lang.Integer instead of Long?
>
> The same holds for java.lang.Double and OCL's Real.
>
> What do you think about this? Or did I misunderstand the problem?
>
> Andreas
>
>> Hi, Andreas,
>>
>> It will require some thought to figure out how to reconcile EMF's
>> ELong with
>> OCL which only recognizes a single Integer type. If you can
>> contribute a
>> patch that resolves the conundrum while maintaining compatibility, I
>> will
>> be more than happy to process it!
>> Cheers,
>>
>> Christian
>>
<snip>
|
|
|
Re: Operations on ELong [message #37241 is a reply to message #37207] |
Fri, 14 September 2007 14:37 |
Andreas Werner Messages: 55 Registered: July 2009 |
Member |
|
|
Hello Christian,
Ok, I will have a look on this stuff! Perhaps I can do something...
Andreas
> Hi, Andreas,
>
> Of course, the OMG is only concerned with the mathematical notions of
> integer, natural, and real numbers, which are not constrained by the
> precision of a binary representation.
>
> It isn't as easy as just changing to use java.lang.Long for integer
> values because that would be an API-breaking change. And why
> java.lang.Long? Why not BigInteger for infinite precision?
>
> There wasn't any specific decision to use java.lang.Integer that I
> know of.
> The problem, now, is how to deal with the fact that some Ecore models
> will
> supply Long values that we have to be able to accommodate. That
> requires
> more time than I can afford just now, which is why solutions/patches
> that
> resolve the problem without breaking compatibility are most welcome.
> It's
> not that I don't think it's an important problem to solve, but it just
> isn't a priority for me and my employer at this time.
> One avenue to pursue would be to enhance the EvaluationVisitor
> implementation to automatically cast numbers to Long during the
> evaluation 9for maximal arithmetic precision), and convert them to
> Integer before returning them to clients whenever possible. In this
> way, existing clients still get Integers because they could only have
> been using Integers before, anyway (else, failing with run-time
> exceptions because their values overflow). Future clients can rely on
> the abstract Number API to get long values for any number if they
> choose, or be more adaptable to whether they see Integer or Long
> results. This would also have to account for coercing Longs to
> Integers when passing them as arguments to user-defined operations,
> etc.
>
> Is that something you might like to work on?
>
> Cheers,
>
> Christian
>
> Andreas Werner wrote:
>
>> Hello Christian,
>>
>> in my opinion the solution is to use java.lang.Long for OCL's type
>> Integer within the implementation! I cannot believe, that OMG says
>> java.lang.Integer must be used. Or, why did the Eclipse.OCL team
>> decide to take java.lang.Integer instead of Long?
>>
>> The same holds for java.lang.Double and OCL's Real.
>>
>> What do you think about this? Or did I misunderstand the problem?
>>
>> Andreas
>>
>>> Hi, Andreas,
>>>
>>> It will require some thought to figure out how to reconcile EMF's
>>> ELong with
>>> OCL which only recognizes a single Integer type. If you can
>>> contribute a
>>> patch that resolves the conundrum while maintaining compatibility, I
>>> will
>>> be more than happy to process it!
>>> Cheers,
>>> Christian
>>>
> <snip>
>
|
|
|
Re: Operations on ELong [message #37275 is a reply to message #37241] |
Fri, 14 September 2007 14:58 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andreas,
Great! If you have questions along the way, the bugzilla and the
mdt.ocl-dev mailing list are both good venues for continuing discussion
(the latter, perhaps, to a lesser degree). I'm actively monitoring both,
of course.
Thanks,
Christian
Andreas Werner wrote:
> Hello Christian,
>
> Ok, I will have a look on this stuff! Perhaps I can do something...
>
> Andreas
>
>> Hi, Andreas,
>>
>> Of course, the OMG is only concerned with the mathematical notions of
>> integer, natural, and real numbers, which are not constrained by the
>> precision of a binary representation.
>>
>> It isn't as easy as just changing to use java.lang.Long for integer
>> values because that would be an API-breaking change. And why
>> java.lang.Long? Why not BigInteger for infinite precision?
>>
>> There wasn't any specific decision to use java.lang.Integer that I
>> know of.
>> The problem, now, is how to deal with the fact that some Ecore models
>> will
>> supply Long values that we have to be able to accommodate. That
>> requires
>> more time than I can afford just now, which is why solutions/patches
>> that
>> resolve the problem without breaking compatibility are most welcome.
>> It's
>> not that I don't think it's an important problem to solve, but it just
>> isn't a priority for me and my employer at this time.
>> One avenue to pursue would be to enhance the EvaluationVisitor
>> implementation to automatically cast numbers to Long during the
>> evaluation 9for maximal arithmetic precision), and convert them to
>> Integer before returning them to clients whenever possible. In this
>> way, existing clients still get Integers because they could only have
>> been using Integers before, anyway (else, failing with run-time
>> exceptions because their values overflow). Future clients can rely on
>> the abstract Number API to get long values for any number if they
>> choose, or be more adaptable to whether they see Integer or Long
>> results. This would also have to account for coercing Longs to
>> Integers when passing them as arguments to user-defined operations,
>> etc.
>>
>> Is that something you might like to work on?
>>
>> Cheers,
>>
>> Christian
------8<------
|
|
|
Goto Forum:
Current Time: Mon Sep 23 02:28:49 GMT 2024
Powered by FUDForum. Page generated in 0.03879 seconds
|