Home » Modeling » OCL » Invalid vs. OCLInvalid
| Invalid vs. OCLInvalid [message #44244] |
Thu, 22 November 2007 13:54  |
Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello!
I see that the type 'OCLInvalid', defined as an instance of the metatype
'InvalidType' in the OCL spec. is named as 'Invalid' both in the
oclstdlib.ecore and the oclstdlib.uml. Is this a typo? If it is, I assume
that this change will be considered carefully since it clearly breaks
compatibility with existing projects depending on current oclstdlib
versions.
This issue is related with a possible refactoring of Shadow Classes, where
natural inheritance relationships are established and therefore many
operations repeated in every class could be concentrated in OCLAny_Class.
I am aware to a certain degree about the refactoring progress conducted in
OCL and I think that this matter has already been considered. I would be
very grateful if some estimation of how long you think these issues would
be taken care of (if they are!) could be thrown to the list.
Thank you very much!!!
Victor
|
|
|
| Re: Invalid vs. OCLInvalid [message #44333 is a reply to message #44244] |
Thu, 22 November 2007 14:45  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
"OclInvalid" (note the mixed case) is the sole instance of the class
"Invalid" which is the sole instance of the metaclass "InvalidType".
Chapter 11 "OCL Standard Library" of the OCL spec seems to be at odds with
usage throughout the rest of the document, indicating that the invalid
value is named "invalid" and its type is named "OclInvalid". MDT OCL chose
to resolve this inconsistency by taking the convention used throughout the
rest of the document (esp. in Chapter 8 "Abstract Syntax").
Does that answer your question? I'm not sure that I understood, in
particular about refactoring the shadow classes ... there is an enhancement
request on consolidation of the operations, but I don't see how that
relates to OclInvalid.
Cheers,
Christian
Victor Sanchez wrote:
> Hello!
>
> I see that the type 'OCLInvalid', defined as an instance of the metatype
> 'InvalidType' in the OCL spec. is named as 'Invalid' both in the
> oclstdlib.ecore and the oclstdlib.uml. Is this a typo? If it is, I assume
> that this change will be considered carefully since it clearly breaks
> compatibility with existing projects depending on current oclstdlib
> versions.
>
> This issue is related with a possible refactoring of Shadow Classes, where
> natural inheritance relationships are established and therefore many
> operations repeated in every class could be concentrated in OCLAny_Class.
> I am aware to a certain degree about the refactoring progress conducted in
> OCL and I think that this matter has already been considered. I would be
> very grateful if some estimation of how long you think these issues would
> be taken care of (if they are!) could be thrown to the list.
>
> Thank you very much!!!
>
> Victor
|
|
|
| Re: Invalid vs. OCLInvalid [message #44362 is a reply to message #44333] |
Thu, 22 November 2007 15:18 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Ok, yes, it does answer my question perfectly :)
About the oclstdlib shadow classes subject, the only resemblance I was
considering regarding to the 'Invalid' naming decision is that
modifications of the oclstdlib can potentially affect lots
of client projects already in use.
On a side note and as far as I am concerned, I am eager for shadow class
refactorings to happen as soon as possible, just so you don't think it is
the other way around. :)
Cheers!
Victor
On Thu, 22 Nov 2007 09:45:19 -0500, Christian W. Damus wrote:
> Hi, Victor,
>
> "OclInvalid" (note the mixed case) is the sole instance of the class
> "Invalid" which is the sole instance of the metaclass "InvalidType".
> Chapter 11 "OCL Standard Library" of the OCL spec seems to be at odds with
> usage throughout the rest of the document, indicating that the invalid
> value is named "invalid" and its type is named "OclInvalid". MDT OCL chose
> to resolve this inconsistency by taking the convention used throughout the
> rest of the document (esp. in Chapter 8 "Abstract Syntax").
>
> Does that answer your question? I'm not sure that I understood, in
> particular about refactoring the shadow classes ... there is an enhancement
> request on consolidation of the operations, but I don't see how that
> relates to OclInvalid.
>
> Cheers,
>
> Christian
>
> Victor Sanchez wrote:
>
>> Hello!
>>
>> I see that the type 'OCLInvalid', defined as an instance of the metatype
>> 'InvalidType' in the OCL spec. is named as 'Invalid' both in the
>> oclstdlib.ecore and the oclstdlib.uml. Is this a typo? If it is, I assume
>> that this change will be considered carefully since it clearly breaks
>> compatibility with existing projects depending on current oclstdlib
>> versions.
>>
>> This issue is related with a possible refactoring of Shadow Classes, where
>> natural inheritance relationships are established and therefore many
>> operations repeated in every class could be concentrated in OCLAny_Class.
>> I am aware to a certain degree about the refactoring progress conducted in
>> OCL and I think that this matter has already been considered. I would be
>> very grateful if some estimation of how long you think these issues would
>> be taken care of (if they are!) could be thrown to the list.
>>
>> Thank you very much!!!
>>
>> Victor
|
|
|
| Re: Invalid vs. OCLInvalid [message #44460 is a reply to message #44362] |
Thu, 22 November 2007 17:29 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
I'm glad that helped.
On the subject of the standard library, are you referring to this bug?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=189657
I can't say when it might be completed because I can't compel anyone to work
on it. I don't have the wherewithal to fix it, myself, and I understand
from Adolfo that he is busy with other things at the moment, too. I'm sure
he would appreciate help on this as much as I would! :-)
Cheers,
Christian
Victor Sanchez wrote:
> Ok, yes, it does answer my question perfectly :)
>
> About the oclstdlib shadow classes subject, the only resemblance I was
> considering regarding to the 'Invalid' naming decision is that
> modifications of the oclstdlib can potentially affect lots
> of client projects already in use.
>
> On a side note and as far as I am concerned, I am eager for shadow class
> refactorings to happen as soon as possible, just so you don't think it is
> the other way around. :)
>
> Cheers!
>
> Victor
-----8<-----
|
|
|
| Re: Invalid vs. OCLInvalid [message #44672 is a reply to message #44460] |
Sun, 25 November 2007 14:08 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hi, Christian!
Thank you for your answer!
> On the subject of the standard library, are you referring to this bug?
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=189657
Yes, this is the one indeed!
> I can't say when it might be completed because I can't compel anyone to work
> on it. I don't have the wherewithal to fix it, myself, and I understand
> from Adolfo that he is busy with other things at the moment, too. I'm sure
> he would appreciate help on this as much as I would! :-)
Ok, Adolfo's pace will surely suit me.
Concerning this bug, I have a request to make. From what I understand from
the OCL specification, all predefined types can be considered as
subclasses of OCLAny. Since we have shadow classes (Ecore 'EClass'es) in
the oclstdlib.ecore and the Primitive Types in UML contain the
'generalization' or 'general' (I'm not sure as to which must be used,
provided it isn't both simultaneously) associations both inherited from
'Classifier', wouldn't it be beneficial to take advantage of inheritance
relationships between types in the OCL standard library as defined in the
project? This would naturally propagate AnyType operations to other types
(except for the predefined collections, which would follow their own
independent inheritance hierarchy). A simpler example would consist of
making the Integer_Class to inherit from Real_Class (in conformance to what
the OCL specification states in section 11.4.1), so it would have
visibility to all the operations defined in Real_Class and only has to
redefine its own. This only affects the metamodel and I don't have any
idea what impact could it have upon the code in the OCL project that
manages this part. I could consult Adolfo about it to make sure that he
already has these considerations in mind, if you want.
For possible bindings with other metamodels, I understand the shadow
classes' approach could work well in case the primitive type concept of the
new bound metamodel did not have built-in inheritance relationships
defined.
I don't know if these suggestions should be part of bug n. #189657,
or they should become a separate bug to be addressed in parallel with
it (or the request should be withdrawn for whatever reason!)
;)
So that's why I post these thoughts here before contributing a post in
the aforementioned bug's page.
Thank you very much!!!
Victor
|
|
|
| Re: Invalid vs. OCLInvalid [message #44737 is a reply to message #44672] |
Mon, 26 November 2007 15:07 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
See some replies in-line, below.
Cheers,
Christian
Victor Sanchez wrote:
> Hi, Christian!
>
> Thank you for your answer!
>
>> On the subject of the standard library, are you referring to this bug?
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=189657
>
> Yes, this is the one indeed!
>
>> I can't say when it might be completed because I can't compel anyone to
>> work
>> on it. I don't have the wherewithal to fix it, myself, and I understand
>> from Adolfo that he is busy with other things at the moment, too. I'm
>> sure
>> he would appreciate help on this as much as I would! :-)
>
> Ok, Adolfo's pace will surely suit me.
>
> Concerning this bug, I have a request to make. From what I understand from
> the OCL specification, all predefined types can be considered as
> subclasses of OCLAny. Since we have shadow classes (Ecore 'EClass'es) in
> the oclstdlib.ecore and the Primitive Types in UML contain the
> 'generalization' or 'general' (I'm not sure as to which must be used,
> provided it isn't both simultaneously) associations both inherited from
> 'Classifier', wouldn't it be beneficial to take advantage of inheritance
> relationships between types in the OCL standard library as defined in the
> project? This would naturally propagate AnyType operations to other types
> (except for the predefined collections, which would follow their own
> independent inheritance hierarchy). A simpler example would consist of
> making the Integer_Class to inherit from Real_Class (in conformance to
> what the OCL specification states in section 11.4.1), so it would have
> visibility to all the operations defined in Real_Class and only has to
> redefine its own. This only affects the metamodel and I don't have any
> idea what impact could it have upon the code in the OCL project that
> manages this part. I could consult Adolfo about it to make sure that he
> already has these considerations in mind, if you want.
Yes, this design resulted originally from the fact that EDataTypes in Ecore
cannot declare generalization relationships, and all of this was originally
implemented via EDataTypes before the library was serialized as a resource.
The shadow classes certainly should have these generalization
relationships. The problem, of course, is that all of the user model types
also specialize OclAny, which of course cannot be done literally and has
conceptual issues, anyway (many classifiers in UML, such as interfaces and
artifacts, are not permitted to specialize a Class).
It would be helpful to append your comments to the bug.
> For possible bindings with other metamodels, I understand the shadow
> classes' approach could work well in case the primitive type concept of
> the new bound metamodel did not have built-in inheritance relationships
> defined.
>
> I don't know if these suggestions should be part of bug n. #189657,
> or they should become a separate bug to be addressed in parallel with
> it (or the request should be withdrawn for whatever reason!)
> ;)
Nope, these suggestions pertain to the problem expressed in that bug, so
that is the appropriate vehicle for them.
> So that's why I post these thoughts here before contributing a post in
> the aforementioned bug's page.
>
> Thank you very much!!!
>
> Victor
|
|
|
Goto Forum:
Current Time: Fri Apr 19 13:11:24 GMT 2024
Powered by FUDForum. Page generated in 0.02682 seconds |
] 
Search
Help
Register
Login
Home
