| [tigerstripe-dev] RE: Some questions. |
|
Hi Richard, See my comments inline. Eric From: Richard
Craddock (rcraddoc) 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. Still going.... RC |