Home » Modeling » OCL » Possible bug in the AbstractTypeResolver implementation
| Possible bug in the AbstractTypeResolver implementation [message #52731] |
Thu, 13 March 2008 08:11  |
Eclipse User |
|
|
|
Hi Christian,
I think that I have encountered a little bug.
When a TypeResolver is resolving a collection (and set, bag,etc) type,
it tries to find the collection in the collectionPackage, and it will
create the collection, if it is not found.
When you pass the AnyType T, as the elementType of a collection (and
set, bag, etc), a new type will be created in the collectionPackage,
while the unique instance (OCLStandarddLibrary.getCollection()) should
be returned...
This simple code (applied to each kind of collection) would improve the
implementation, because and unnecessary type is not created (and used by
expressions) when resolving Collection(T).
// Documentation copied from the inherited specification
@SuppressWarnings("unchecked")
public CollectionType<C, O> resolveCollectionType(
CollectionKind kind,
C elementType) {
OCLStandardLibrary<C> stdlib = getEnvironment().getOCLStandardLibrary();
if (elementType.equals(stdlib.getT()))
return (CollectionType<C, O>) stdlib.getCollection();
CollectionType<C, O> result = findCollectionType(kind, elementType);
if (result == null) {
result = createCollectionType(kind, elementType);
}
return result;
}
If you agree, I could raise a bugzilla with a patch solving this little
issue.
Regards,
Adolfo.
|
|
|
| Re: Possible bug in the AbstractTypeResolver implementation [message #52761 is a reply to message #52731] |
Thu, 13 March 2008 09:23  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
Absolutely, that looks like a problem worth fixing.
Just be sure to account for the appropriate CollectionKind. Your snippet,
below, appears to return Collection(T) for all collection kinds.
Thanks!
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
>
> I think that I have encountered a little bug.
>
> When a TypeResolver is resolving a collection (and set, bag,etc) type,
> it tries to find the collection in the collectionPackage, and it will
> create the collection, if it is not found.
>
> When you pass the AnyType T, as the elementType of a collection (and
> set, bag, etc), a new type will be created in the collectionPackage,
> while the unique instance (OCLStandarddLibrary.getCollection()) should
> be returned...
>
> This simple code (applied to each kind of collection) would improve the
> implementation, because and unnecessary type is not created (and used by
> expressions) when resolving Collection(T).
>
> // Documentation copied from the inherited specification
> @SuppressWarnings("unchecked")
> public CollectionType<C, O> resolveCollectionType(
> CollectionKind kind,
> C elementType) {
>
> OCLStandardLibrary<C> stdlib = getEnvironment().getOCLStandardLibrary();
> if (elementType.equals(stdlib.getT()))
> return (CollectionType<C, O>) stdlib.getCollection();
>
> CollectionType<C, O> result = findCollectionType(kind, elementType);
>
> if (result == null) {
> result = createCollectionType(kind, elementType);
> }
>
> return result;
> }
>
> If you agree, I could raise a bugzilla with a patch solving this little
> issue.
>
> Regards,
> Adolfo.
|
|
|
| Re: Possible bug in the AbstractTypeResolver implementation [message #52788 is a reply to message #52761] |
Thu, 13 March 2008 10:50 |
| Eclipse User |
|
|
|
Hi Christian,
Bug raised:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=222581
Commets in-line
> Hi, Adolfo,
>
> Absolutely, that looks like a problem worth fixing.
>
> Just be sure to account for the appropriate CollectionKind. Your snippet,
> below, appears to return Collection(T) for all collection kinds.
Your are certainly right. I hadn't realized that this method manages all
the collections. I have taken into account your comment in the attached
patch.
>
> Thanks!
It's a pleasure.
Cheers,
Adolfo.
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> I think that I have encountered a little bug.
>>
>> When a TypeResolver is resolving a collection (and set, bag,etc) type,
>> it tries to find the collection in the collectionPackage, and it will
>> create the collection, if it is not found.
>>
>> When you pass the AnyType T, as the elementType of a collection (and
>> set, bag, etc), a new type will be created in the collectionPackage,
>> while the unique instance (OCLStandarddLibrary.getCollection()) should
>> be returned...
>>
>> This simple code (applied to each kind of collection) would improve the
>> implementation, because and unnecessary type is not created (and used by
>> expressions) when resolving Collection(T).
>>
>> // Documentation copied from the inherited specification
>> @SuppressWarnings("unchecked")
>> public CollectionType<C, O> resolveCollectionType(
>> CollectionKind kind,
>> C elementType) {
>>
>> OCLStandardLibrary<C> stdlib = getEnvironment().getOCLStandardLibrary();
>> if (elementType.equals(stdlib.getT()))
>> return (CollectionType<C, O>) stdlib.getCollection();
>>
>> CollectionType<C, O> result = findCollectionType(kind, elementType);
>>
>> if (result == null) {
>> result = createCollectionType(kind, elementType);
>> }
>>
>> return result;
>> }
>>
>> If you agree, I could raise a bugzilla with a patch solving this little
>> issue.
>>
>> Regards,
>> Adolfo.
>
|
|
|
Goto Forum:
Current Time: Fri Apr 25 01:26:59 EDT 2025
Powered by FUDForum. Page generated in 0.03280 seconds |
Home