[Tm4j-developers] Re: Re: TopicMapFactory refactoring

[Kal A. <ka...@te...>]

On Monday 16 December 2002 17:43, Ren...@da... wrote:
> ReHi Kal,
>
> In general it sounds good and I am really looking forward to these chan=
ges
> to see how your API will work together with our research project.
>
> In the end it is your decision when to do the refactoring considering t=
hese
> conceptional aspects. But due to my experiences it is advisable to do t=
hem
> as early as possible. The more code you have and the more backends are
> implemented the bigger and more complex are the changes you will have t=
o
> do. If I where you I would even go further. I would fix the memory back=
end
> first until it would seem perfect to me. Afterward I would adapt the
> results to the other backends. If you consider the resource time, I thi=
nk
> you would need less of it this way. But you are the manager of this pro=
ject
> and that is why you make the decisions.
>

It is a balancing act between developing the features that people have=20
requested (such as RDBMS persistance); the features I want (like the unif=
ied=20
topic map); and spending time on the other work such as API improvements;=
=20
documentation improvements and so on. There is a cost in changing the API=
 all=20
the time, but on the flip-side, working with persistent storage mechanism=
s=20
such as Ozone/Hibernate has made me reconsider a number of things about t=
he=20
original in-memory-only API, so it is sometimes beneficial to be forced t=
o=20
implement against both in-memory and persistent back-ends.

> By the way - I have another point which can be improved, I think ;-)
>
> When creating a BaseName for Example you use the method
> createBaseName(String id). This method will use the Constructor public
> BaseName(TopicMap tm, String id) or something like that. All in all you=
 can
> only create a BaseName with an id. If there is the wish to add a
> BaseNameString you have to add it with the add method of BaseName. I th=
ink
> the user is not interrested in the id mostly when creating a BaseName. =
What
> is interressting for him is the BaseNameString. Sometimes he does not w=
ant
> to concern about the id at all. That is why you should give him the
> opportunity to let the API generate the id. There could be two methods.
>
> createBaseName(parent) if the user is not interessted in the id
> and
> createBaseName(String id, parent) if the user wants to choose an id him=
self
> and
> createBaseNameString(String baseNameString, parent);
>
> or later:
> Topic.createBaseName()
> and
> Topic.createBaseName(String id)
> and
> BaseName.createBaseNameString(String baseNameString)
>

Those are good suggestions to carry forward to the next re-working of the=
 API.=20
Although I think that I would treat the baseNameString as a property of=20
BaseName, not as a child object. That means that you would have=20
BaseName.setBaseNameString() (or as it is currently called=20
BaseName.setData()).

> The same is also true of other child elements of  a Topic Map which
> usability could be improved. But this can wait until the TM API interfa=
ces
> are implemented, because you will have to change this afterwards again.
> What I consider to be the most important thing now, is to adapt TM API
> interfaces to TM4J.
>

It should probably be done at the same time, though I am still thinking t=
hat=20
this should be after 0.8.0.

However, I do not see any reason why the time between 0.8.0 and 0.9.0 sho=
uld=20
be as long as it has been between 0.7.0 and 0.8.0.

Cheers,

Kal

--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: ka...@te...
p: +44 7968 529531
w: www.techquila.com