Home » Modeling » OCL » Suggestion of generalizing Ecore CollectionTypes
| Suggestion of generalizing Ecore CollectionTypes [message #30810] |
Tue, 26 June 2007 16:27  |
Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
Hi Christian,
I'm here again :D.
Im working in the OMStandardLibrary at this moment, and i have realized of
some things that i wanted to commment with you.
When you specify the OCL generic metamodel with the EcoreBinding, you finish
the generalization stablishing that the type of the collection's elemente
are EClassifier. I think that you could take adventage of the use of
generics metaelements in EMF 2.3, and allow clients to specify the type of
the collection's elements.
Instead of stablishing in the OCLEcore metamodel that:
CollectionType -> EDataType, CollectionType<EClassifier, EOperation>
you could do it in this way:
CollectionType<C extends EClassifier> -> EDataType, CollectionType<C,
EOperation>
In addition of being is more flexible, this generalization is needed for me,
since im working with OCLEcore metamodel, and i have some new types (List<T>
or DictionaryType<KeyT, T>) that should extend OCLEcore CollectionType, and
it doesnt allow element type specification.
i think that this generelization would be useful for UML Metamodel Binding
too.
Regards,
Adolfo.
|
|
|
| Re: Suggestion of generalizing Ecore CollectionTypes [message #30847 is a reply to message #30810] |
Tue, 26 June 2007 18:30  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
I don't quite understand. Your specializations List<T> and
DictionaryType<KeyT, T> should be able to extend
org.eclipse.ocl.ecore.CollectionType as it is. Why would you need to
redefine its type parameter substitution? This substitution is only there
to serve the OCL parser, and shouldn't be particularly relevant to clients.
The type parameter of CollectionType<C> doesn't represent the type of the
collection's elements, as do the T and KeyT parameters in your
specializations. It ties the Ecore binding of the CollectionType to the
same <C> parameter used throughout the entire OCL API, so this would
require the entire binding of "what is the representation of OCL
Classifier" to be similarly specified as <C extends EClassifier>, but then
other complications of unsafe casting arise because the binding now is an
unknown type.
Can you elaborate some more on what you are trying to do?
Thanks,
Christian
Adolfo S�chez-Barbudo Herrera wrote:
> Hi Christian,
>
> I'm here again :D.
>
> Im working in the OMStandardLibrary at this moment, and i have realized of
> some things that i wanted to commment with you.
>
> When you specify the OCL generic metamodel with the EcoreBinding, you
> finish the generalization stablishing that the type of the collection's
> elemente are EClassifier. I think that you could take adventage of the use
> of generics metaelements in EMF 2.3, and allow clients to specify the type
> of the collection's elements.
>
> Instead of stablishing in the OCLEcore metamodel that:
>
> CollectionType -> EDataType, CollectionType<EClassifier, EOperation>
>
> you could do it in this way:
>
> CollectionType<C extends EClassifier> -> EDataType, CollectionType<C,
> EOperation>
>
> In addition of being is more flexible, this generalization is needed for
> me, since im working with OCLEcore metamodel, and i have some new types
> (List<T> or DictionaryType<KeyT, T>) that should extend OCLEcore
> CollectionType, and it doesnt allow element type specification.
>
> i think that this generelization would be useful for UML Metamodel Binding
> too.
>
> Regards,
> Adolfo.
|
|
|
| Re: Suggestion of generalizing Ecore CollectionTypes [message #31125 is a reply to message #30847] |
Thu, 28 June 2007 09:46 |
| Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
Hi Christian,
Well, i have been mixing concepts and ideas around the collections (and
generics) and the type of the collection's elements.
Some more comments.
> I don't quite understand. Your specializations List<T> and
> DictionaryType<KeyT, T> should be able to extend
> org.eclipse.ocl.ecore.CollectionType as it is. Why would you need to
> redefine its type parameter substitution? This substitution is only there
> to serve the OCL parser, and shouldn't be particularly relevant to
> clients.
Yes my idea was, having generic Lists and Dictionary Types metaelements. But
im thinking that i cant do it since the CollectionType is not generic.
> The type parameter of CollectionType<C> doesn't represent the type of the
> collection's elements, as do the T and KeyT parameters in your
> specializations. It ties the Ecore binding of the CollectionType to the
> same <C> parameter used throughout the entire OCL API, so this would
> require the entire binding of "what is the representation of OCL
> Classifier" to be similarly specified as <C extends EClassifier>, but then
> other complications of unsafe casting arise because the binding now is an
> unknown type.
Yes you are right, and that was my confusion, and perhaps we shouldnt mix
the concept of what is representing the C in the entire OCL API with the
type of collection's elements. But indeed, C is established in
CollectionType<C, O> in order to have the type of the collection's elements
and not for another thing,
|
|
|
| Re: Suggestion of generalizing Ecore CollectionTypes [message #31228 is a reply to message #31125] |
Thu, 28 June 2007 14:31 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
The concrete syntax of OCL collections looks generic:
let apples : Set(Apple) = ... in ...
but in the Abstract Syntax metamodel, these types are not generic. The
CollectionType metaclass has an association to Classifier, named
elementType at its end. The element type is not a template parameter.
To satisfy the need to be able to target different metamodels with different
metaclasses representing the "classifier" concept, the MDT OCL
implementation defines a generic CollectionType parameterized by the
metaclass denoting classifiers. This type parameter is used as the type of
the elementType association end. Thus, CollectionType<EClassifier>
indicates that the metatype of the element type of a collection-type
instance is EClassifier. Different instances of
CollectionType<EClassifier> have different actual element types, which are
any kind of EClassifier.
The generic metaclass
CollectionType<C, O>
- elementType : C
- ...
is bound to Ecore as:
CollectionType<EClassifier, EOperation>
- elementType : EClassifier
- ...
and has instances such as
Set(Apple)
- elementType = FruitPackage.Literals.APPLE // an EClass
Sequence(EDate)
- elementType = EcorePackage.Literals.EDATE // an EDataType
Other specific comments in-line, below.
Cheers,
Christian
Adolfo S�chez-Barbudo Herrera wrote:
> Hi Christian,
>
> Well, i have been mixing concepts and ideas around the collections (and
> generics) and the type of the collection's elements.
>
> Some more comments.
>
>> I don't quite understand. Your specializations List<T> and
>> DictionaryType<KeyT, T> should be able to extend
>> org.eclipse.ocl.ecore.CollectionType as it is. Why would you need to
>> redefine its type parameter substitution? This substitution is only
>> there to serve the OCL parser, and shouldn't be particularly relevant to
>> clients.
>
> Yes my idea was, having generic Lists and Dictionary Types metaelements.
> But im thinking that i cant do it since the CollectionType is not generic.
>
>> The type parameter of CollectionType<C> doesn't represent the type of the
>> collection's elements, as do the T and KeyT parameters in your
>> specializations. It ties the Ecore binding of the CollectionType to the
>> same <C> parameter used throughout the entire OCL API, so this would
>> require the entire binding of "what is the representation of OCL
>> Classifier" to be similarly specified as <C extends EClassifier>, but
>> then other complications of unsafe casting arise because the binding now
>> is an unknown type.
>
> Yes you are right, and that was my confusion, and perhaps we shouldnt mix
> the concept of what is representing the C in the entire OCL API with the
> type of collection's elements. But indeed, C is established in
> CollectionType<C, O> in order to have the type of the collection's
> elements and not for another thing, Am i wrong ?
Not exactly: C is established to have the *metatype* of the type of the
collection's elements.
> When in java5 you have an EList<String> better than a EList, you are
> saying that the elements of the list are Strings better than Object.
> in EMF 2.3 you could say that CollectionType<StringLiteralExp> better than
> a CollectionType, and you would be saying that elements of the collection
> are
> StringLiteraExp (then EClass, then EClassifier) better than EClassifiers.
Generic types are good for more than just collections, though. The case of
EList<E> is a model class (M1 level) that uses a generic type parameter as
the type of its element list. CollectionType<C, O> is a metaclass (M2
level) that uses a generic type parameter as the type of its elementType
property, i.e., as the type of the type of its elements.
> So, since we dont have generic CollectionTypes, an example of a definition
> of a DictionaryType operation, such as DictionaryType<KeyT,T>::get(k:KeyT)
> : T, i would have to define it in my metamodel as a
> DictionaryType<KeyT>::get(k:KeyT): EClassifier.
No, I think you would have:
DictionaryType<KeyT, T> -> CollectionType
- get(k : KeyT) : T
Actually, more to the point, it would probably make more sense if you really
want the dictionary to fit in with other OCL collection types, to define it
as a metaclass:
DictionaryType -> SetType
- keyType : EClassifier
using a property of type EClassifier to represent the key type as
CollectionType does for the elementType. Then, a particular instance of
this might be
Dictionary(Apple, Color)
- keyType = FruitPackage.Literals.APPLE // an EClass
- elementType = FruitPackage.Literals.COLOR // an EEnum
This instance of the DictionaryType metaclass is, then, an EDataType
describing a dictionary of Fruit-Color mappings.
>
> Best Regards,
> Adolfo.
|
|
|
| Re: Suggestion of generalizing Ecore CollectionTypes [message #31263 is a reply to message #31228] |
Thu, 28 June 2007 15:52 |
| Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
Well, eventually, i think that my fault is that i m thinking in a bad
M-level. Im trying to generalize the types at M2 level when it should be
done at M1 level.
I will work more about this questions, and i'll go back again with my
doubts/conclusions ;).
Whereas, i'll set the DictionaryType as follows:
DictionaryType -> CollectionType.
keyType: EClassifier.
+ get(k:EClassifier) : EClassifier.
...
Thanks a lot for your replies.
Greetings,
Adolfo.
> The concrete syntax of OCL collections looks generic:
>
> let apples : Set(Apple) = ... in ...
>
> but in the Abstract Syntax metamodel, these types are not generic. The
> CollectionType metaclass has an association to Classifier, named
> elementType at its end. The element type is not a template parameter.
>
> To satisfy the need to be able to target different metamodels with
> different
> metaclasses representing the "classifier" concept, the MDT OCL
> implementation defines a generic CollectionType parameterized by the
> metaclass denoting classifiers. This type parameter is used as the type
> of
> the elementType association end. Thus, CollectionType<EClassifier>
> indicates that the metatype of the element type of a collection-type
> instance is EClassifier. Different instances of
> CollectionType<EClassifier> have different actual element types, which are
> any kind of EClassifier.
>
> The generic metaclass
>
> CollectionType<C, O>
> - elementType : C
> - ...
>
> is bound to Ecore as:
>
> CollectionType<EClassifier, EOperation>
> - elementType : EClassifier
> - ...
>
> and has instances such as
>
> Set(Apple)
> - elementType = FruitPackage.Literals.APPLE // an EClass
>
> Sequence(EDate)
> - elementType = EcorePackage.Literals.EDATE // an EDataType
>
> Other specific comments in-line, below.
>
> Cheers,
>
> Christian
>
>
> Adolfo S?chez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Well, i have been mixing concepts and ideas around the collections (and
>> generics) and the type of the collection's elements.
>>
>> Some more comments.
>>
>>> I don't quite understand. Your specializations List<T> and
>>> DictionaryType<KeyT, T> should be able to extend
>>> org.eclipse.ocl.ecore.CollectionType as it is. Why would you need to
>>> redefine its type parameter substitution? This substitution is only
>>> there to serve the OCL parser, and shouldn't be particularly relevant to
>>> clients.
>>
>> Yes my idea was, having generic Lists and Dictionary Types metaelements.
>> But im thinking that i cant do it since the CollectionType is not
>> generic.
>>
>>> The type parameter of CollectionType<C> doesn't represent the type of
>>> the
>>> collection's elements, as do the T and KeyT parameters in your
>>> specializations. It ties the Ecore binding of the CollectionType to the
>>> same <C> parameter used throughout the entire OCL API, so this would
>>> require the entire binding of "what is the representation of OCL
>>> Classifier" to be similarly specified as <C extends EClassifier>, but
>>> then other complications of unsafe casting arise because the binding now
>>> is an unknown type.
>>
>> Yes you are right, and that was my confusion, and perhaps we shouldnt mix
>> the concept of what is representing the C in the entire OCL API with the
>> type of collection's elements. But indeed, C is established in
>> CollectionType<C, O> in order to have the type of the collection's
>> elements and not for another thing, Am i wrong ?
>
> Not exactly: C is established to have the *metatype* of the type of the
> collection's elements.
>
>
>> When in java5 you have an EList<String> better than a EList, you are
>> saying that the elements of the list are Strings better than Object.
>> in EMF 2.3 you could say that CollectionType<StringLiteralExp> better
>> than
>> a CollectionType, and you would be saying that elements of the collection
>> are
>> StringLiteraExp (then EClass, then EClassifier) better than
>> EClassifiers.
>
> Generic types are good for more than just collections, though. The case
> of
> EList<E> is a model class (M1 level) that uses a generic type parameter as
> the type of its element list. CollectionType<C, O> is a metaclass (M2
> level) that uses a generic type parameter as the type of its elementType
> property, i.e., as the type of the type of its elements.
>
>
>> So, since we dont have generic CollectionTypes, an example of a
>> definition
>> of a DictionaryType operation, such as
>> DictionaryType<KeyT,T>::get(k:KeyT)
>> : T, i would have to define it in my metamodel as a
>> DictionaryType<KeyT>::get(k:KeyT): EClassifier.
>
> No, I think you would have:
>
> DictionaryType<KeyT, T> -> CollectionType
> - get(k : KeyT) : T
>
> Actually, more to the point, it would probably make more sense if you
> really
> want the dictionary to fit in with other OCL collection types, to define
> it
> as a metaclass:
>
> DictionaryType -> SetType
> - keyType : EClassifier
>
> using a property of type EClassifier to represent the key type as
> CollectionType does for the elementType. Then, a particular instance of
> this might be
>
> Dictionary(Apple, Color)
> - keyType = FruitPackage.Literals.APPLE // an EClass
> - elementType = FruitPackage.Literals.COLOR // an EEnum
>
> This instance of the DictionaryType metaclass is, then, an EDataType
> describing a dictionary of Fruit-Color mappings.
>
>>
>> Best Regards,
>> Adolfo.
>
|
|
|
| Re: Suggestion of generalizing Ecore CollectionTypes [message #31293 is a reply to message #31263] |
Thu, 28 June 2007 16:18 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
I look forward to your conclusions! You've been very helpful on this and
other matters, finding problems (and solutions) and generally prompting me
to think. :-)
cW
Adolfo S�chez-Barbudo Herrera wrote:
> Well, eventually, i think that my fault is that i m thinking in a bad
> M-level. Im trying to generalize the types at M2 level when it should be
> done at M1 level.
>
> I will work more about this questions, and i'll go back again with my
> doubts/conclusions ;).
>
> Whereas, i'll set the DictionaryType as follows:
>
> DictionaryType -> CollectionType.
> keyType: EClassifier.
>
> + get(k:EClassifier) : EClassifier.
> ...
>
> Thanks a lot for your replies.
>
> Greetings,
> Adolfo.
<snip>
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 13:31:27 GMT 2024
Powered by FUDForum. Page generated in 0.03041 seconds |
] 
Search
Help
Register
Login
Home
