Just checked on the 3 classes: Primitive,
AssocClass and UpdareProc.
The “getLabel()” method was
fixed properly, so there was no harm in removing the statics. (I must have
missed it).
Eric
From: Richard
Craddock (rcraddoc)
Sent: Monday, March 03, 2008 2:03
AM
To: Eric Dillon (erdillon)
Cc: 'Tigerstripe developers list'
Subject: RE: Some odd things...
From: Eric
Dillon (erdillon)
Sent: 29 February 2008 23:35
To: Richard Craddock (rcraddoc)
Cc: 'Tigerstripe developers list'
Subject: RE: Some odd things...
Hi Richard,
See my comments inline.
Eric
From: Richard
Craddock (rcraddoc)
Sent: Friday, February 29, 2008
8:31 AM
To: Eric Dillon (erdillon)
Cc: Tigerstripe
developers list
Subject: Some odd things...
I've been adding Javadoc to all of
the methods in the api :-)
[ER>] Cool!
I came across a few odd bits and
pieces:
1. Three of the
Artifact types had a static String called DEFAULT_LABEL. This was never
referenced anywhere. I deleted it in all 3 cases.
[ER>] Hmmm. I thought I had removed them
all. Unfortunately, they were used through some odd Reflection. Which ones were
these?
RC - Primitive type, Association Class and
Update Procedure
2. IManagedEntityArtifact
has a getPrimaryKey() method. I cannot find a setter for this anywhere, neither
do I have any idea what it is for! I think that the logic should have been
moved to IossjEntitySpecifics, and this just got left behind. I have not
deleted this without your agreement. (If we do delete it, then the inner class
IPrimaryKey can go as well. (You have these in the new metamodel - don't forget
to remove it there as well if you agree).
[ER>] Yes. I agree this should be
deleted. As you do so though we need to check that the “persist”
templates don’t make use of them. In fact I realized yesterday that when
we removed getMethodReturnName to getReturnName we broke the corresponding
feature because the “persist” template used it. (in the base
plugin, in org.eclipse.tigerstripe.workbench.internal.core.model.persist )
RC -
Good point, but in this case everything is set up to use the PrimaryKey in the
specifics, so the templates do not need to change.
3. I think we have lost the javadoc
descriptions for a lot of classes in the API - the class definitions themselves.
[ER>] I’m hoping to change the
build scripts on Monday to have that javadoc created and uploaded somewhere. We
should be able to get a better overall perspective then…
There are a few things that I don't
know whether we should still have in the API.
AbstractArtifact,IMethod - I
have moved them to the end of the respective files.
RC -
Still need to review these bits