Home » Modeling » OCL » Bug getting the CollectionType Name
| Bug getting the CollectionType Name [message #33366] |
Wed, 18 July 2007 13:33  |
Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
Hi Christian:
Trying to edit My QVTOperational model in the Sample Ecore Editor leads me
to an internal error when i create a new CollectionType in the model.
This is caused because getName method of CollectionTypeImpl (Specific
implementation with an Ecore or UML Binding) assume that the collection has
its ElementType set.
I suggest modifying the method in a safer way, or delegating resolution of
the ElementType name to the UMLReflection class as you do with the Generic
CollectionTypeImpl:
String getName() {
...
if (elementType instanceof VoidType) {
elementTypeName = "T"; //$NON-NLS-1$
} else {
elementTypeName = elementType == null ? null :
elementType.getName();
}
...
}
or
String getName() {
...
if (elementType instanceof VoidType) {
elementTypeName = "T"; //$NON-NLS-1$
} else if (elementType instanceof PredefinedType) {
elementTypeName = elementType.getName();
} else {
elementTypeName = env.getUMLReflection().getName(elementType);
...
}
Some questions:
1. Why have you named T as the name of the elements which have voidType. I
have in mind that T is associated with AnyType.
|
|
|
| Re: Bug getting the CollectionType Name [message #33411 is a reply to message #33366] |
Wed, 18 July 2007 14:04  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
A CollectionType isn't valid if it doesn't have an elementType, but it would
be nice not to throw exceptions if it can be helped. Please raise a bug.
I'm not sure why "T" is used for when the element type is OclVoid; I will
have to look into that. I would have thought that "OclVoid" (which is the
name of the void type) would be more appropriate. Perhaps you can raise a
bug for that, too?
Regarding the edit and editor plug-ins: there hadn't been a need identified
for these previously, and in the 1.0 release it wasn't even possible to
serialize an expression, so an editor wasn't particularly interesting. I
suppose it is common practice to provide these, though, but they will be
quite large. Please raise an enhancement request and we'll see about doing
this for the 1.2 release. The editing plug-ins really ought to be owned by
the OCL component.
Thanks,
Christian
Adolfo S�chez-Barbudo Herrera wrote:
> Hi Christian:
>
> Trying to edit My QVTOperational model in the Sample Ecore Editor leads me
> to an internal error when i create a new CollectionType in the model.
> This is caused because getName method of CollectionTypeImpl (Specific
> implementation with an Ecore or UML Binding) assume that the collection
> has its ElementType set.
>
> I suggest modifying the method in a safer way, or delegating resolution of
> the ElementType name to the UMLReflection class as you do with the Generic
> CollectionTypeImpl:
>
> String getName() {
> ...
> if (elementType instanceof VoidType) {
> elementTypeName = "T"; //$NON-NLS-1$
> } else {
> elementTypeName = elementType == null ? null :
> elementType.getName();
> }
> ...
> }
>
> or
>
> String getName() {
> ...
> if (elementType instanceof VoidType) {
> elementTypeName = "T"; //$NON-NLS-1$
> } else if (elementType instanceof PredefinedType) {
> elementTypeName = elementType.getName();
> } else {
> elementTypeName = env.getUMLReflection().getName(elementType);
> ...
> }
>
> Some questions:
> 1. Why have you named T as the name of the elements which have voidType. I
> have in mind that T is associated with AnyType. Wouldnt it be better
> naming it null ?. In QVTOperational Especification is the name selected
> for voidType.
>
> 2 Is there any reason of not having the Edit and Editor plugin of the OCL
> Metamodels ?. I have had to generate them ir order to have my
> QVTOperational editor.
>
> Thank you very much in advance ;)
>
> Greetings,
> Adolfo.
|
|
|
| Re: Bug getting the CollectionType Name [message #33436 is a reply to message #33411] |
Wed, 18 July 2007 15:14 |
| Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
> A CollectionType isn't valid if it doesn't have an elementType, but it
> would
> be nice not to throw exceptions if it can be helped. Please raise a bug.
Yes it shouldn't be valid, and the problem is when you create an EClassifier
CollectionType in the Editor you cant stablish his ElementType at time, so
the getName methods throws an exception when you do elementType.getName().
I had some similar problems with exception, when persisting types (and this
getName method) because i was not establising correctly the type for some
new ImperativeExpressions, that finally had a Collection with ElementType =
null, and when tryed to persist the new generated types, the process
crashed.
The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=196967
> I'm not sure why "T" is used for when the element type is OclVoid; I will
> have to look into that. I would have thought that "OclVoid" (which is the
> name of the void type) would be more appropriate. Perhaps you can raise a
> bug for that, too?
Yes, probably the TypeElement name of the VoidType should be taken directly
from elementType.getName(), as the same as the rest of types (for example a
PrimitiveType).
Perhaps you wanted to reflect that the name of the AnyType is T, better than
OclAny, as you have considered in the oclstandardlib types for example
(where you have Set(T), Bag(T)). Anyway, we are agree that assigning T as
the name of elements with VoidType type should not be appropiate. You will
have to decide to use OclAny or T for the Elements with AnyType type.
The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=196972
> Regarding the edit and editor plug-ins: there hadn't been a need
> identified
> for these previously, and in the 1.0 release it wasn't even possible to
> serialize an expression, so an editor wasn't particularly interesting. I
> suppose it is common practice to provide these, though, but they will be
> quite large. Please raise an enhancement request and we'll see about
> doing
> this for the 1.2 release. The editing plug-ins really ought to be owned
> by
> the OCL component.
Great !!! It will be helpfull to edit models which conformance directly or
indirectly with OCL Metamodel
The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=196973
Best Regards,
Adolfo.
|
|
|
| Re: Bug getting the CollectionType Name [message #33471 is a reply to message #33436] |
Wed, 18 July 2007 15:52 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
See some replies in-line, below.
Cheers,
Christian
Adolfo S�chez-Barbudo Herrera wrote:
>> A CollectionType isn't valid if it doesn't have an elementType, but it
>> would
>> be nice not to throw exceptions if it can be helped. Please raise a bug.
>
> Yes it shouldn't be valid, and the problem is when you create an
> EClassifier CollectionType in the Editor you cant stablish his ElementType
> at time, so the getName methods throws an exception when you do
> elementType.getName(). I had some similar problems with exception, when
> persisting types (and this getName method) because i was not establising
> correctly the type for some new ImperativeExpressions, that finally had a
> Collection with ElementType = null, and when tryed to persist the new
> generated types, the process crashed.
I suppose that, for now, you could customize your CollectionType item
provider's create command to set OclAny as an initial elementType.
> The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=196967
>
>> I'm not sure why "T" is used for when the element type is OclVoid; I will
>> have to look into that. I would have thought that "OclVoid" (which is
>> the
>> name of the void type) would be more appropriate. Perhaps you can raise
>> a bug for that, too?
>
> Yes, probably the TypeElement name of the VoidType should be taken
> directly from elementType.getName(), as the same as the rest of types (for
> example a PrimitiveType).
> Perhaps you wanted to reflect that the name of the AnyType is T, better
> than OclAny, as you have considered in the oclstandardlib types for
> example (where you have Set(T), Bag(T)). Anyway, we are agree that
> assigning T as the name of elements with VoidType type should not be
> appropiate. You will have to decide to use OclAny or T for the Elements
> with AnyType type.
"T" should only be appropriate for the special AnyType instance that
represents the generic T type parameter. This T should only occur in the
Set(T) etc. instances in the OCL Standard Library. Other AnyTypes should
just use the names that they were assigned.
I'll need to find out, though, why this was done in the first place (it
seems deliberate). I need to understand any potential dependencies on this
behaviour before I change it ...
> The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=196972
>
>> Regarding the edit and editor plug-ins: there hadn't been a need
>> identified
>> for these previously, and in the 1.0 release it wasn't even possible to
>> serialize an expression, so an editor wasn't particularly interesting. I
>> suppose it is common practice to provide these, though, but they will be
>> quite large. Please raise an enhancement request and we'll see about
>> doing
>> this for the 1.2 release. The editing plug-ins really ought to be owned
>> by
>> the OCL component.
>
> Great !!! It will be helpfull to edit models which conformance directly
> or indirectly with OCL Metamodel
As I mentioned in a comment on the enhancement request, the tricky bit will
be the packaging (as everything else is generated). I don't suppose you
would be interested in contributing meaningful icons for the edit
providers? I don't expect to have the wherewithal to create any ...
> The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=196973
>
> Best Regards,
> Adolfo.
|
|
|
| Re: Bug getting the CollectionType Name [message #33704 is a reply to message #33471] |
Mon, 23 July 2007 11:10 |
| Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
Hi Christian,
About your contribution proposal ;)
>
> As I mentioned in a comment on the enhancement request, the tricky bit
> will
> be the packaging (as everything else is generated). I don't suppose you
> would be interested in contributing meaningful icons for the edit
> providers? I don't expect to have the wherewithal to create any ...
Im sorry, but i think that im not your man for this job, i hv not idea about
design :P.
Besides, im deeped in the QVT implementation, and at the moment im more
worried about low-level problems which concerns the parsing of QVT and its
OCL expresions, and all the extensibility problems surrounding this task.
The editor would be a future question ;).
Greetings,
Adolfo.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:22:27 GMT 2024
Powered by FUDForum. Page generated in 0.03162 seconds |
] 
Search
Help
Register
Login
Home
