| Resolving generic types [message #1705938] |
Thu, 20 August 2015 09:45  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm mapping some Ecore classes to the type system of GraphQL
(https://facebook.github.io/graphql/#sec-Type-System). Each GraphQL
object type has a set of fields that roughly corresponds to Ecore's
features. So from an EClass with a name feature of type EString I can
generate a GraphQL object type with a name field of type String.
However, this is complicated by the fact that GraphQL does not support
generics.
Suppose an EClass is parameterised with T and has a t feature of that
type. It cannot be included in the corresponding GraphQL object type,
since it isn't resolved:
class A<T> {
t : T; // cannot be mapped to GraphQL
}
However, a subclass may provide type arguments that makes it possible
to include it in the GraphQL object type for the subclass:
class B extends A<EString> {
// the t feature is now known to be of type EString
}
Hence, I in general need to resolve all types and check if they are
completely resolved.
I'm sure resolving Ecore types has been done before, so the question is
whether there's any type resolver code I can (re)use. I think that a
smart EcoreUtil.Copier may do the trick, but want to ask before writing
my own.
Hallvard
--
Hallvard Trætteberg (hal@xxxxxxxx.no)
Associate Professor, IS group, Dept. of Computer and Information
Science at the
Norwegian Univ. of Science and Technology
|
|
|
| Re: Resolving generic types [message #1705947 is a reply to message #1705938] |
Thu, 20 August 2015 10:55  |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Probably you're looking to use
org.eclipse.emf.ecore.EClass.getFeatureType(EStructuralFeature).
On 20/08/2015 11:45 AM, Hallvard Trætteberg wrote:
> Hi,
>
> I'm mapping some Ecore classes to the type system of GraphQL
> (https://facebook.github.io/graphql/#sec-Type-System). Each GraphQL
> object type has a set of fields that roughly corresponds to Ecore's
> features. So from an EClass with a name feature of type EString I can
> generate a GraphQL object type with a name field of type String.
> However, this is complicated by the fact that GraphQL does not support
> generics.
>
> Suppose an EClass is parameterised with T and has a t feature of that
> type. It cannot be included in the corresponding GraphQL object type,
> since it isn't resolved:
>
> class A<T> {
> t : T; // cannot be mapped to GraphQL
> }
>
> However, a subclass may provide type arguments that makes it possible
> to include it in the GraphQL object type for the subclass:
>
> class B extends A<EString> {
> // the t feature is now known to be of type EString
> }
>
> Hence, I in general need to resolve all types and check if they are
> completely resolved.
>
> I'm sure resolving Ecore types has been done before, so the question
> is whether there's any type resolver code I can (re)use. I think that
> a smart EcoreUtil.Copier may do the trick, but want to ask before
> writing my own.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Resolving generic types [message #1705970 is a reply to message #1705947] |
Thu, 20 August 2015 14:00 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Very probably, thanks!
On 2015-08-20 10:55:39 +0000, Ed Merks said:
> Hallvard,
>
> Probably you're looking to use
> org.eclipse.emf.ecore.EClass.getFeatureType(EStructuralFeature).
>
>
> On 20/08/2015 11:45 AM, Hallvard Trætteberg wrote:
>> Hi,
>>
>> I'm mapping some Ecore classes to the type system of GraphQL
>> (https://facebook.github.io/graphql/#sec-Type-System). Each GraphQL
>> object type has a set of fields that roughly corresponds to Ecore's
>> features. So from an EClass with a name feature of type EString I can
>> generate a GraphQL object type with a name field of type String.
>> However, this is complicated by the fact that GraphQL does not support
>> generics.
>>
>> Suppose an EClass is parameterised with T and has a t feature of that
>> type. It cannot be included in the corresponding GraphQL object type,
>> since it isn't resolved:
>>
>> class A<T> {
>> t : T; // cannot be mapped to GraphQL
>> }
>>
>> However, a subclass may provide type arguments that makes it possible
>> to include it in the GraphQL object type for the subclass:
>>
>> class B extends A<EString> {
>> // the t feature is now known to be of type EString
>> }
>>
>> Hence, I in general need to resolve all types and check if they are
>> completely resolved.
>>
>> I'm sure resolving Ecore types has been done before, so the question is
>> whether there's any type resolver code I can (re)use. I think that a
>> smart EcoreUtil.Copier may do the trick, but want to ask before writing
>> my own.
>>
>> Hallvard
--
Hallvard Trætteberg (hal@xxxxxxxx.no)
Associate Professor, IS group, Dept. of Computer and Information
Science at the
Norwegian Univ. of Science and Technology
|
|
|
Powered by
FUDForum. Page generated in 0.01834 seconds
] 
Search
Help
Register
Login
Home
