[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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.
3) I currently am of the opinion that we are only contained
by a single object.
RC
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
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