Home » Modeling » EMF » Modeling implicits (how to?)
| Modeling implicits (how to?) [message #1073100] |
Wed, 24 July 2013 06:19  |
 Leonid Ripeynih
Messages: 150
Registered: February 2012 |
Senior Member |
|
|
Hi!
How to model things, which have some implicit, for example, containments? Lets take the following description: 'Pipeline can have some declared ports, and implicitly declares a port named 'source''
So, whenever I see something like
<pipeline>
<port name="my-port" />
</pipeline>
I should treat it as it was
<pipeline>
<port name="source" />
<port name="my-port" />
</pipeline>
I'm thinking of two approaches to model that thing:
1. Overriding generated getPort code (not exactly overriding, but creating getPortGen method to be able to re-generate the code), than returning the DelegatingEList, that can add new ports to original backing list (from getPort), and will always return implicits in it's get methods.
2. Creating one more feature (like allPorts) and doing things in getAllPorts, returning an UnmodifiableEList.
Is there any (better) ways of modeling implicits? Is there any implemented examples I can learn from?
|
|
|
| Re: Modeling implicits (how to?) [message #1073109 is a reply to message #1073100] |
Wed, 24 July 2013 06:50  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Leonid,
Comments below.
On 24/07/2013 8:19 AM, Leonid Ripeynih wrote:
> Hi!
> How to model things, which have some implicit, for example,
> containments? Lets take the following description: 'Pipeline can have
> some declared ports, and implicitly declares a port named 'source''
>
> So, whenever I see something like
> <pipeline>
> <port name="my-port" />
> </pipeline>
>
> I should treat it as it was
>
> <pipeline>
> <port name="source" />
> <port name="my-port" />
> </pipeline>
>
> I'm thinking of two approaches to model that thing:
> 1. Overriding generated getPort code (not exactly overriding, but
> creating getPortGen method to be able to re-generate the code), than
> returning the DelegatingEList, that can add new ports to original
> backing list (from getPort), and will always return implicits in it's
> get methods.
That sounds problematic. EcoreUtil.copy will copy them all and the
serializer will serialize them all. So how to deal with something
that's implicitly there also being explicitly added during
deserialization and copying
> 2. Creating one more feature (like allPorts) and doing things in
> getAllPorts, returning an UnmodifiableEList.
Such a feature could be transient, derived, and read only, so it
wouldn't be serialized, wouldn't be copied, and wouldn't be changeable.
But a derived reference can't be a containment reference (because an
EObject x knows it's contained by x.eContainer() and knows that it's in
x.eContainer().eGet(x.eContainmentReference()), so you'd also need to
model a containment reference to contain the implicit port; if that
feature is also transient, derived, and read only, you could populate it
in the constructor.
>
> Is there any (better) ways of modeling implicits? Is there any
> implemented examples I can learn from?
I can't think of any examples just like this. Depending on your goal,
you could avoid this entirely and instead define a constraint or
invariant that a Pipeline must have a first port named "source" if it
has any ports, and specialize the Pipeline item provider's command
creation to try to maintain this constraint, i.e., when a Port is added
to a Pipeline, you add two ports if there are currently none...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Modeling implicits (how to?) [message #1073146 is a reply to message #1073109] |
Wed, 24 July 2013 08:09 |
Leonid Ripeynih
Messages: 150
Registered: February 2012 |
Senior Member |
|
|
Ed Merks wrote on Wed, 24 July 2013 02:50
That sounds problematic. EcoreUtil.copy will copy them all and the
serializer will serialize them all. So how to deal with something
that's implicitly there also being explicitly added during
deserialization and copying
In that context, implicit means, it will never be added explicitly, and adding another port named 'source' will just violate constraint on unique port name, just like adding two ports named 'my-port' will. Also, backing list is featureMap.list, so any features already marked as transient, derived and volatile. Does it make it a better idea in that case?
Ed Merks wrote on Wed, 24 July 2013 02:50
Such a feature could be transient, derived, and read only, so it
wouldn't be serialized, wouldn't be copied, and wouldn't be changeable.
But a derived reference can't be a containment reference (because an
EObject x knows it's contained by x.eContainer() and knows that it's in
x.eContainer().eGet(x.eContainmentReference()), so you'd also need to
model a containment reference to contain the implicit port; if that
feature is also transient, derived, and read only, you could populate it
in the constructor.
Am I understand you correctly, that we're forcing a user of the model to read from one feature (say, 'allPorts') to get the whole picture, and write to another (say, 'ports')? And writing to allPorts shoud be prohibited, and allPorts should be UnmodifiableEList?
Ed Merks wrote on Wed, 24 July 2013 02:50
I can't think of any examples just like this. Depending on your goal,
you could avoid this entirely and instead define a constraint or
invariant that a Pipeline must have a first port named "source" if it
has any ports, and specialize the Pipeline item provider's command
creation to try to maintain this constraint, i.e., when a Port is added
to a Pipeline, you add two ports if there are currently none...
I think you didn't understand me entirely. Pipeline will always have the 'source' port, and can have arbitrary number of user defined ports. But 'source' is always here, ready to be connected and referenced by pipes. And that port will never appear in serialized XML. So, any ways to make sure it's here from the moment pipeline is created?
Thanks for you attention.
|
|
|
| Re: Modeling implicits (how to?) [message #1073180 is a reply to message #1073146] |
Wed, 24 July 2013 09:19 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Leonid,
Comments below.
On 24/07/2013 10:09 AM, Leonid Ripeynih wrote:
> Ed Merks wrote on Wed, 24 July 2013 02:50
>> That sounds problematic. EcoreUtil.copy will copy them all and the
>> serializer will serialize them all. So how to deal with something
>> that's implicitly there also being explicitly added during
>> deserialization and copying
>
>
> In that context, implicit means, it will never be added explicitly,
> and adding another port named 'source' will just violate constraint on
> unique port name, just like adding two ports named 'my-port' will.
> Also, backing list is featureMap.list, so any features already marked
> as transient, derived and volatile. Does it make it a better idea in
> that case?
It's hard to say without the full details of the model.
>
> Ed Merks wrote on Wed, 24 July 2013 02:50
>> Such a feature could be transient, derived, and read only, so it
>> wouldn't be serialized, wouldn't be copied, and wouldn't be
>> changeable. But a derived reference can't be a containment reference
>> (because an EObject x knows it's contained by x.eContainer() and
>> knows that it's in x.eContainer().eGet(x.eContainmentReference()), so
>> you'd also need to model a containment reference to contain the
>> implicit port; if that feature is also transient, derived, and read
>> only, you could populate it in the constructor.
>
>
> Am I understand you correctly, that we're forcing a user of the model
> to read from one feature (say, 'allPorts') to get the whole picture,
> and write to another (say, 'ports')? And writing to allPorts shoud be
> prohibited, and allPorts should be UnmodifiableEList?
I thought that was your proposal...
> Ed Merks wrote on Wed, 24 July 2013 02:50
>> I can't think of any examples just like this. Depending on your
>> goal, you could avoid this entirely and instead define a constraint
>> or invariant that a Pipeline must have a first port named "source" if
>> it has any ports, and specialize the Pipeline item provider's command
>> creation to try to maintain this constraint, i.e., when a Port is
>> added to a Pipeline, you add two ports if there are currently none...
>
>
> I think you didn't understand me entirely. Pipeline will always have
> the 'source' port, and can have arbitrary number of user defined ports.
I see.
> But 'source' is always here, ready to be connected and referenced by
> pipes. And that port will never appear in serialized XML.
I see.
> So, any ways to make sure it's here from the moment pipeline is created?
You can do things in the constructor, and assuming you've got things set
up so that EcoreUtil.copy doesn't duplicate the implicit "always there"
port, that nothing ever deletes it, and that's it's not serialized and
hence not deserialized, I suppose that should work.
So if you think you have it right, test if EcoreUtil.copy works properly
and that save/load round-trips it properly.
>
> Thanks for you attention.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 18:25:51 GMT 2024
Powered by FUDForum. Page generated in 0.02632 seconds |
] 
Search
Help
Register
Login
Home
