| Re: [tigerstripe-dev] Containment |
John,
Moving between packages should be handled through a "proper" refactor - and we should change the containment that way. I am now resolved to the position that half of these methods should be hidden from the API. If our containment model here is based on where things "live" rather than any additional dependencies defined in the model, then we should expose "gets" only.
I will throw exceptions for any invalid operation.
RC
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of John Worrell (jworrell)
Sent: 26 June 2008 16:41
To: Tigerstripe developers list
Subject: RE: [tigerstripe-dev] Containment
A comment or two inline...
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Craddock (rcraddoc)
Sent: 26 June 2008 16:43
To: Tigerstripe developers list
Subject: RE: [tigerstripe-dev] Containment
1) Yes - we will be keeping this in synch - on reflection maybe I should hide a couple of these to stop people screwing the model totally!
2) Not sure we need to have a remove... They should disappear when they are removed from the model - which begs the question why we expose the add/set methods...I'm becoming more attuned to hiding stuff.[JohnW] :-) It might be that we have to move from one package to another... so remove then add?
3) I currently am of the opinion that we are only contained by a single object. [JohnW] But what if an artifact is added to a given container twice -I assume we only want it there once. - we either reject silently or throw an exception on the second add - 2 options.
RC
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of John Worrell (jworrell)
Sent: 26 June 2008 15:59
To: Tigerstripe developers list
Subject: RE: [tigerstripe-dev] Containment
Looks OK to me... some small questions...
1) I assume addContainedMC(s) would set the ref to the ContainingMC and vice versa
2) do we need a removeContainedMC?
3) is there an implicit constraint to the effect that a given MC can be contained only once? (Should that be reflected in returning a Set<...>?) What are the semantics of failure if that constraintexists?
Cheers,
JohnW
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Craddock (rcraddoc)
Sent: 26 June 2008 15:59
To: Tigerstripe developers list
Subject: [tigerstripe-dev] Containment
All,
(especially John)
as part of the work to add Packages to the list of supported Artifacts, we are proposing to add some methods to IModelComponent.
Does the following list look reasonable/complete.
public void setContainingModelComponent(IModelComponent containingComponent) throws TigerstripeException;
public IModelComponent getContainingModelComponent();
public void addContainedModelComponents(Collection<IModelComponent> components) throws TigerstripeException;
public void addContainedModelComponent(IModelComponent component) throws TigerstripeException;
public Collection<IModelComponent> getContainedModelComponents();
The basic idea is that Package Artifacts will contain instances of packageArtifacts and the existing ArtifactTypes.
Existing Artifacts will contain Fields, Methods, Literals etc
Methods could in turn contain Arguments (if they were properly Modelled!) this might need to wait for EMF before we make that change!
Adding an invalid thing (eg saying a Field contains an Artifact) would throw an Exception.
Cheers,
Richard
_______________________________________________
tigerstripe-dev mailing list
tigerstripe-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev