Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Possible bug in the AbstractTypeResolver implementation
Possible bug in the AbstractTypeResolver implementation [message #52731] Thu, 13 March 2008 08:11 Go to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo Herrera
Messages: 253
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
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 Go to previous message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo Herrera
Messages: 253
Registered: July 2009
Senior Member
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.
>
Previous Topic:[Announce] MDT OCL 1.2.0 I200803121800 is available
Next Topic:OCL Variables
Goto Forum:
  


Current Time: Fri Aug 29 18:28:42 EDT 2014

Powered by FUDForum. Page generated in 0.01854 seconds