[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
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
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
