alexroldugin / spray

Automatically exported from code.google.com/p/spray
0 stars 0 forks source link

eContainer should be selectable for connection ends #57

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
The from and to attribute of a connection should accept eContainer.
This allows modelling connections for which one of the ends is the semantic 
container. E.g UML Generalization.

class Generalizaton  :
    connection (width=1) [
        from eContainer;
        to general;
]

Currently eContainer is not available, since it is an eOperation property of 
EObject Class and not an eStructuralFeature. 

Original issue reported on code.google.com by veit.hof...@googlemail.com on 4 Nov 2011 at 8:26

GoogleCodeExporter commented 8 years ago
If the eContainer should be used this way,  there should be a reference from 
Generalization to the eContainer.  If this reference is not in the metamodel it 
should not be used in the from and to.

Original comment by joswar...@gmail.com on 5 Nov 2011 at 4:09

GoogleCodeExporter commented 8 years ago
The eContainer is somehow special. It is a kind of implicit reference, and I 
think it should be possible to specify it as possible end points.

Original comment by karsten....@googlemail.com on 7 Nov 2011 at 11:12

GoogleCodeExporter commented 8 years ago
The eContainer is special in tyhe sense that it is a necessary implementation 
property from EMF.  If you really want to use the reference to the container in 
a model you should model it explicitly in your ecore model. This also ensures 
it gets a proper understandable name. It is bad style to use the eContainer 
this way.

Original comment by joswar...@gmail.com on 8 Nov 2011 at 12:58

GoogleCodeExporter commented 8 years ago
I'm not sure anymore and thinking that Jos will be right here. Question is how 
this should be enabled for what Veit wants to express, namely specifying the 
connection for an UML Generalization.

Maybe this related to issue#60, where the containment reference into which an 
element is inserted is specified for the create behavior.

And maybe this makes the 'from' side of a connection optional.

I have to see this in an example.

Original comment by karsten....@googlemail.com on 15 Nov 2011 at 12:20

GoogleCodeExporter commented 8 years ago
@ 4 I don't think that's wise. One can easily think of a Model where the target 
of an edge has the container role. Thus you wouldn't gain much by making 'from' 
optional. I think it is better to make the container property optional, as it 
is now. This works for all cases where one of the ends has container role. In 
all other cases one needs to set the container property explicitely.

Original comment by veit.hof...@googlemail.com on 15 Nov 2011 at 6:34

GoogleCodeExporter commented 8 years ago
I agree with veit.

Original comment by joswar...@gmail.com on 16 Nov 2011 at 10:02

GoogleCodeExporter commented 8 years ago

Original comment by joswar...@gmail.com on 22 Nov 2012 at 1:04