Cool. More comments below.
Eric
From: Richard
Craddock (rcraddoc)
Sent: Wednesday, February 20, 2008
4:02 AM
To: Tigerstripe developers list;
Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] RE:
Some questions.
Eric,
all your fixes are good.
Item 3 . Change made.
Item 6. My bad.
IRelationshipEnd already has a getOtherEnd(). no change needed.
Re: bug 217290 - Should
this simply throw a TigerstripeException if the type being attempted to set is
invalid?
This makes me think of a
few other things - like if I create anything through the API, bit don't set a
Type - what should the app do? Allow you to save it anyway? (I think that is
what happens now). Maybe we should have some "minimal requirements"
to make an attribute/field/method etc valid ?
[ER>] what’s the correct bug number… this is
not a Tigerstripe bug. I tried some combination but couldn’t guess J.
I believe we have some validation logic being triggered
through the UI, not sure how it’s hook in the API. If it is not, it would
need to be! I’d prefer to look into this within the context of the EMF
move though unless it is a quick fix.
RC
From:
tigerstripe-dev-bounces@xxxxxxxxxxx
[mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On
Behalf Of Richard Craddock (rcraddoc)
Sent: 20 February 2008 09:05
To: Eric Dillon (erdillon)
Cc: Tigerstripe developers list
Subject: [tigerstripe-dev] RE:
Some questions.
Hi Eric,
good work!
I'll be carrying on
today, but have a process question - if you (or anyone else) have fixed a bug
and I'm happy with it should I close it, or de we wait until we have a formal
build with it in?
From: Eric
Dillon (erdillon)
Sent: 20 February 2008 00:38
To: Richard Craddock (rcraddoc)
Cc: Jim Strawn (jistrawn); Duncan
Keysell (dkeysell); 'Tigerstripe developers list'
Subject: RE: Some questions.
Hi Richard,
See my comments inline.
Eric
From: Richard
Craddock (rcraddoc)
Sent: Tuesday, February 19, 2008
8:34 AM
To: Eric
Dillon (erdillon)
Cc: Jim Strawn (jistrawn); Duncan Keysell (dkeysell)
Subject: Some questions.
I raised bugs where I could. Heres a
variety of thoughts/questions
[ER>] I’ve addressed 219420,
219444, 219450, 219454, 217823, 217825. This will be in tonight’s nightly
build.
1. What is the option "Cascade
Delete References" for in the Preferences/General tab for ? I've never
noticed it before......
[ER>] I initially couldn’t
remember what this could be, but I remember talking with Chris about this case:
when deleting an artifact from the model that has incoming or outgoing
associations, these associations/relations are currently left “dangling”.
This option mean that all relationships would be removed as well. I am unclear
as what is really implemented, so I would be in favor of removing this option
from the GUI until we can vouch for what it really means L.
2. I think we need to review the
OSS/J settings in the "factory default" profile - the OSS/J specifics
appear unless you turn them off - should be the reverse ?
[ER>] Agreed. The OSSJ settings should
all be turned off by default.
3. On Method we have a method called
getMethodReturnName() - is might be simpler to just have getReturnName()
[ER>] Please make the change.
4. I seem to remember that
*somewhere* in the code you can query an AbstractArtifact to see if it supports
Methods, Constants etc. This might be quite handy to add to the API. And add a
similar thing to say if it has Ends.
[ER>] As discussed briefly on the phone
today, I think it makes sense to provide a way to “introspect” the
artifacts. This will be needed/available from the EMF implementation later on.
I was hoping to get around to doing it today… not sure anymore.
I’ll send you an email if I do finish this tonight.
5. Isn't the refBy stuff really an
OSS/J specific ?
[ER>] Hmmm…. This needs to be
thought thru. It should indeed be considered as an OSSJ extension in the
metamodel, but it is currently embedded quite deeply in the core, so we have
look at the consequences…
6. On an associationEnd - there is
no current method to say if it is the AEnd or ZEnd of a relationship - I'm not
sure exactly what this truly means in context as the navigability are the truly
useful things, but we have had to do some (admittedly simple) checking whenever
we want to get the "otherEnd". Maybe a couple of methods could be
added isAEnd() isZEnd() ?
[ER>] I believe there is a getOtherEnd()
method on the implementation of IAssociationEnd. It should simply be a matter
of pushing this into the IAssociationEnd Interface and it should do the trick?
7. (Warning - Modelling question!) Still on the
associationEnd - we have Multiplicity, but we also have a type which has
multiplicity - the TypeMultiplicity is always 0..1 - should that be 1, or is it
really irrelevant?
[ER>] Yes. This is a bit redundant.
IAssociationEnd exposes a multiplicity, and the IType on that end does too. For
consistency we should probably use the IType one only. Also, we need to look
into migrating the current Enumeration-based multiplicity to support arbitrary
bounds (upperBound, lowerBound).
8. (This is very minor) when I add
an attribute to an artifact it generates the names attriubute0, attribute1,
attriubute2 . If I then switch artifact, it starts at attriubute2 ....
[ER>] Yes, a little annoyance indeed,
maybe there is a “static” somewhere we should remove J.