Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » Binding of generics' type parameters
Binding of generics' type parameters [message #556050] Mon, 30 August 2010 16:46 Go to next message
Simon Barner is currently offline Simon BarnerFriend
Messages: 8
Registered: August 2010
Junior Member
Dear forum,

I have a question regarding the use of generics in ecore models which I came across when defining the following meta model (full source code at the bottom of this message)


  • Abstract class Component<D extends Domain> containing 1..* Port<D extends Domain>
  • Abstract class Port<D extends Domain>
  • Concrete domains D1 and D2 (inheriting from Domain)
  • Concrete components C{1,2} inheriting from Component<D{1,2}>)
  • Concrete ports P{1,2} inheriting from Port<D{1,2}>)


When creating a dynamic instance of C1, both the "sample reflective ecore model editor" and the "generic emf form editor" allow me to add insert child objects of type P1 and P2, i.e. C1's type parameter D1 is not bound to the "ports" reference.

My question: Is this the intended semantics of Ecore generic types, or is this simply a restriction of the two editors mentioned above? AFAICT from the genmodel source code and what I remember from Java Generics, the available types for the types reference should be restricted to P1?

Thank you very much in advance,
Simon

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
    nsURI="www.example.com/test" nsPrefix="test">
  <eClassifiers xsi:type="ecore:EClass" name="Domain"/>
  <eClassifiers xsi:type="ecore:EClass" name="D1" eSuperTypes="#//Domain"/>
  <eClassifiers xsi:type="ecore:EClass" name="D2" eSuperTypes="#//Domain"/>
  <eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true">
    <eTypeParameters name="D">
      <eBounds eClassifier="#//Domain"/>
    </eTypeParameters>
    <eStructuralFeatures xsi:type="ecore:EReference" name="ports" upperBound="-1"
        containment="true">
      <eGenericType eClassifier="#//Port">
        <eTypeArguments eTypeParameter="#//Component/D"/>
      </eGenericType>
    </eStructuralFeatures>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="C1">
    <eGenericSuperTypes eClassifier="#//Component">
      <eTypeArguments eClassifier="#//D1"/>
    </eGenericSuperTypes>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="C2">
    <eGenericSuperTypes eClassifier="#//Component">
      <eTypeArguments eClassifier="#//D2"/>
    </eGenericSuperTypes>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="Port" abstract="true">
    <eTypeParameters name="D">
      <eBounds eClassifier="#//Domain"/>
    </eTypeParameters>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="P1">
    <eGenericSuperTypes eClassifier="#//Port">
      <eTypeArguments eClassifier="#//D1"/>
    </eGenericSuperTypes>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="P2">
    <eGenericSuperTypes eClassifier="#//Port">
      <eTypeArguments eClassifier="#//D2"/>
    </eGenericSuperTypes>
  </eClassifiers>
</ecore:EPackage>

P.S.: This is my first post to the Eclipse forums, so please kindly point me to your guidelines in case I missed something...

Report message to a moderator

Re: Binding of generics' type parameters [message #556064 is a reply to message #556050] Mon, 30 August 2010 17:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33133
Registered: July 2009
Senior Member
Simon,

Comments below.

Simon Barner wrote:
> Dear forum,
>
> I have a question regarding the use of generics in ecore models which
> I came across when defining the following meta model (full source code
> at the bottom of this message)
Best to ask in the EMF newsgroup: eclipse.tools.emf
>
>
> Abstract class Component<D extends Domain> containing 1..* Port<D
> extends Domain>
> Abstract class Port<D extends Domain>
> Concrete domains D1 and D2 (inheriting from Domain)
> Concrete components C{1,2} inheriting from Component<D{1,2}>)
> Concrete ports P{1,2} inheriting from Port<D{1,2}>)
>
>
> When creating a dynamic instance of C1, both the "sample reflective
> ecore model editor" and the "generic emf form editor" allow me to add
> insert child objects of type P1 and P2, i.e. C1's type parameter D1 is
> not bound to the "ports" reference.
Sounds a bit like https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859
>
> My question: Is this the intended semantics of Ecore generic types, or
> is this simply a restriction of the two editors mentioned above?
> AFAICT from the genmodel source code and what I remember from Java
> Generics, the available types for the types reference should be
> restricted to P1?
If it's like the above problem, the problem is that something that's
allowed in the base class ends up not being allowed in the derived
class; choice of child creation in the above case. So for Component
any Domain instance is allowed. But later in a move concretely derived
class, that's no longer true. But nothing is generated to override what
was allowed in the base class. And of course at runtime, there's
generally no knowledge about how the generic type was instantiated;
it's erased. It's only in this situation where the instantiation
information is available via reflection of the inheritance hierarchy or
of the feature types that we could know more. I've seen the term
reification used for this type of scenario. I've just not had time to
look into all the places where this additional information (information
not available in the erased type system) can be used to further
constrain the behavior of the editor or further constrain the fail-fast
type safety of the APIs.
>
> Thank you very much in advance,
> Simon
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
> nsURI="www.example.com/test" nsPrefix="test">
> <eClassifiers xsi:type="ecore:EClass" name="Domain"/>
> <eClassifiers xsi:type="ecore:EClass" name="D1"
> eSuperTypes="#//Domain"/>
> <eClassifiers xsi:type="ecore:EClass" name="D2"
> eSuperTypes="#//Domain"/>
> <eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true">
> <eTypeParameters name="D">
> <eBounds eClassifier="#//Domain"/>
> </eTypeParameters>
> <eStructuralFeatures xsi:type="ecore:EReference" name="ports"
> upperBound="-1"
> containment="true">
> <eGenericType eClassifier="#//Port">
> <eTypeArguments eTypeParameter="#//Component/D"/>
> </eGenericType>
> </eStructuralFeatures>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="C1">
> <eGenericSuperTypes eClassifier="#//Component">
> <eTypeArguments eClassifier="#//D1"/>
> </eGenericSuperTypes>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="C2">
> <eGenericSuperTypes eClassifier="#//Component">
> <eTypeArguments eClassifier="#//D2"/>
> </eGenericSuperTypes>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Port" abstract="true">
> <eTypeParameters name="D">
> <eBounds eClassifier="#//Domain"/>
> </eTypeParameters>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="P1">
> <eGenericSuperTypes eClassifier="#//Port">
> <eTypeArguments eClassifier="#//D1"/>
> </eGenericSuperTypes>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="P2">
> <eGenericSuperTypes eClassifier="#//Port">
> <eTypeArguments eClassifier="#//D2"/>
> </eGenericSuperTypes>
> </eClassifiers>
> </ecore:EPackage>
>
> P.S.: This is my first post to the Eclipse forums, so please kindly
> point me to your guidelines in case I missed something...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Binding of generics' type parameters [message #556167 is a reply to message #556064] Tue, 31 August 2010 08:05 Go to previous message
Simon Barner is currently offline Simon BarnerFriend
Messages: 8
Registered: August 2010
Junior Member
[X-post and f'up to eclipse.tools.emf]

Dear EMF group,

do you have a hint how to tackle this problem that I described in my
post to eclipse.modeling?

Regards,
Simon

Ed Merks wrote:
> Simon Barner wrote:
>> Dear forum,
>>
>> I have a question regarding the use of generics in ecore models which
>> I came across when defining the following meta model (full source code
>> at the bottom of this message)
> Best to ask in the EMF newsgroup: eclipse.tools.emf
>>
>>
>> Abstract class Component<D extends Domain> containing 1..* Port<D
>> extends Domain>
>> Abstract class Port<D extends Domain>
>> Concrete domains D1 and D2 (inheriting from Domain)
>> Concrete components C{1,2} inheriting from Component<D{1,2}>)
>> Concrete ports P{1,2} inheriting from Port<D{1,2}>)
>>
>>
>> When creating a dynamic instance of C1, both the "sample reflective
>> ecore model editor" and the "generic emf form editor" allow me to add
>> insert child objects of type P1 and P2, i.e. C1's type parameter D1 is
>> not bound to the "ports" reference.
> Sounds a bit like https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859
>>
>> My question: Is this the intended semantics of Ecore generic types, or
>> is this simply a restriction of the two editors mentioned above?
>> AFAICT from the genmodel source code and what I remember from Java
>> Generics, the available types for the types reference should be
>> restricted to P1?
>
> If it's like the above problem, the problem is that something that's
> allowed in the base class ends up not being allowed in the derived
> class; choice of child creation in the above case. So for Component any
> Domain instance is allowed. But later in a move concretely derived
> class, that's no longer true. But nothing is generated to override what
> was allowed in the base class. And of course at runtime, there's
> generally no knowledge about how the generic type was instantiated; it's
> erased. It's only in this situation where the instantiation information
> is available via reflection of the inheritance hierarchy or of the
> feature types that we could know more. I've seen the term reification
> used for this type of scenario. I've just not had time to look into all
> the places where this additional information (information not available
> in the erased type system) can be used to further constrain the behavior
> of the editor or further constrain the fail-fast type safety of the APIs.
>>
>> Thank you very much in advance,
>> Simon
>>
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
>> nsURI="www.example.com/test" nsPrefix="test">
>> <eClassifiers xsi:type="ecore:EClass" name="Domain"/>
>> <eClassifiers xsi:type="ecore:EClass" name="D1" eSuperTypes="#//Domain"/>
>> <eClassifiers xsi:type="ecore:EClass" name="D2" eSuperTypes="#//Domain"/>
>> <eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true">
>> <eTypeParameters name="D">
>> <eBounds eClassifier="#//Domain"/>
>> </eTypeParameters>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="ports"
>> upperBound="-1"
>> containment="true">
>> <eGenericType eClassifier="#//Port">
>> <eTypeArguments eTypeParameter="#//Component/D"/>
>> </eGenericType>
>> </eStructuralFeatures>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="C1">
>> <eGenericSuperTypes eClassifier="#//Component">
>> <eTypeArguments eClassifier="#//D1"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="C2">
>> <eGenericSuperTypes eClassifier="#//Component">
>> <eTypeArguments eClassifier="#//D2"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Port" abstract="true">
>> <eTypeParameters name="D">
>> <eBounds eClassifier="#//Domain"/>
>> </eTypeParameters>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="P1">
>> <eGenericSuperTypes eClassifier="#//Port">
>> <eTypeArguments eClassifier="#//D1"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="P2">
>> <eGenericSuperTypes eClassifier="#//Port">
>> <eTypeArguments eClassifier="#//D2"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> </ecore:EPackage>

Report message to a moderator

Re: Binding of generics' type parameters [message #619963 is a reply to message #556064] Tue, 31 August 2010 08:05 Go to previous message
Simon Barner is currently offline Simon BarnerFriend
Messages: 8
Registered: August 2010
Junior Member
[X-post and f'up to eclipse.tools.emf]

Dear EMF group,

do you have a hint how to tackle this problem that I described in my
post to eclipse.modeling?

Regards,
Simon

Ed Merks wrote:
> Simon Barner wrote:
>> Dear forum,
>>
>> I have a question regarding the use of generics in ecore models which
>> I came across when defining the following meta model (full source code
>> at the bottom of this message)
> Best to ask in the EMF newsgroup: eclipse.tools.emf
>>
>>
>> Abstract class Component<D extends Domain> containing 1..* Port<D
>> extends Domain>
>> Abstract class Port<D extends Domain>
>> Concrete domains D1 and D2 (inheriting from Domain)
>> Concrete components C{1,2} inheriting from Component<D{1,2}>)
>> Concrete ports P{1,2} inheriting from Port<D{1,2}>)
>>
>>
>> When creating a dynamic instance of C1, both the "sample reflective
>> ecore model editor" and the "generic emf form editor" allow me to add
>> insert child objects of type P1 and P2, i.e. C1's type parameter D1 is
>> not bound to the "ports" reference.
> Sounds a bit like https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859
>>
>> My question: Is this the intended semantics of Ecore generic types, or
>> is this simply a restriction of the two editors mentioned above?
>> AFAICT from the genmodel source code and what I remember from Java
>> Generics, the available types for the types reference should be
>> restricted to P1?
>
> If it's like the above problem, the problem is that something that's
> allowed in the base class ends up not being allowed in the derived
> class; choice of child creation in the above case. So for Component any
> Domain instance is allowed. But later in a move concretely derived
> class, that's no longer true. But nothing is generated to override what
> was allowed in the base class. And of course at runtime, there's
> generally no knowledge about how the generic type was instantiated; it's
> erased. It's only in this situation where the instantiation information
> is available via reflection of the inheritance hierarchy or of the
> feature types that we could know more. I've seen the term reification
> used for this type of scenario. I've just not had time to look into all
> the places where this additional information (information not available
> in the erased type system) can be used to further constrain the behavior
> of the editor or further constrain the fail-fast type safety of the APIs.
>>
>> Thank you very much in advance,
>> Simon
>>
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
>> nsURI="www.example.com/test" nsPrefix="test">
>> <eClassifiers xsi:type="ecore:EClass" name="Domain"/>
>> <eClassifiers xsi:type="ecore:EClass" name="D1" eSuperTypes="#//Domain"/>
>> <eClassifiers xsi:type="ecore:EClass" name="D2" eSuperTypes="#//Domain"/>
>> <eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true">
>> <eTypeParameters name="D">
>> <eBounds eClassifier="#//Domain"/>
>> </eTypeParameters>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="ports"
>> upperBound="-1"
>> containment="true">
>> <eGenericType eClassifier="#//Port">
>> <eTypeArguments eTypeParameter="#//Component/D"/>
>> </eGenericType>
>> </eStructuralFeatures>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="C1">
>> <eGenericSuperTypes eClassifier="#//Component">
>> <eTypeArguments eClassifier="#//D1"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="C2">
>> <eGenericSuperTypes eClassifier="#//Component">
>> <eTypeArguments eClassifier="#//D2"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Port" abstract="true">
>> <eTypeParameters name="D">
>> <eBounds eClassifier="#//Domain"/>
>> </eTypeParameters>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="P1">
>> <eGenericSuperTypes eClassifier="#//Port">
>> <eTypeArguments eClassifier="#//D1"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="P2">
>> <eGenericSuperTypes eClassifier="#//Port">
>> <eTypeArguments eClassifier="#//D2"/>
>> </eGenericSuperTypes>
>> </eClassifiers>
>> </ecore:EPackage>

Report message to a moderator

Previous Topic:Binding of generics' type parameters
Next Topic:Creating feature-based EMF product
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Apr 16 08:56:17 GMT 2024

Powered by FUDForum. Page generated in 0.70902 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly