Refactoring done (was: Strigi refactor)

[Thomas Zander]

On Friday 16 March 2007 10:47, Jos van den Oever wrote:
> > Clucene has a copy of the classes, and you depend on strigi having an
> > exect copy of the code to make it all work.
> > You said clucene will not change it copy of the classes any other way
> > from strigi.  Now, if you did get hold of that one crystal boll and can
> > predict the future, we are friends. :) If not we should follow the normal
> > rules of maintainable code and that includes minimizing dependencies.
>
> This dependency on the same files is only in  the _implementation_ of
> the cluceneindex directory.

So, there is not a copy f the classes in both projects?

> This is not different from any other 
> library dependency. Our API does not depend on what clucene does. If a
> future version of clucene changes the api, we change only the
> implementation when we want to use that version.

I'm confused;  you can't make the clucene engine to compile if the API of 
strigi is different from the api of strigi.  That is the current state of 
affairs.
Your answer states thats not the case. If you are right, then please alter the 
API implementation of the clucene engine to discouple the two 
implementations.

Or, lets turn it around.  Strigi should alter the implementation of the 
classes (Like InputStream) in several aspects;
* namespace should be Strigi
* classes should use a d-pointer
* we should avoid having getFoo() methods in those classes.

So, instead of waiting for clucene to alter the headers and then fixing the 
implementation of the engine, please do it now.

Thanks
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070316/3b2ce4c3/attachment.sig>