Refactoring done (was: Strigi refactor)

[Thomas Zander]

On Thursday 15 March 2007 21:17, Jos van den Oever wrote:
> > the result is less then optimal; having two namespaces. Can you tell us
> > if there is a (medium term) solution to that?
> > And if that can be implemented before the kde4.0 release?
>
> The reason that it is hard to do away with the jstreams namespace is
> that CLucene uses a few classes that are exactly the same as those in
> Strigi. So for binary compatibility we cannot change these classes. We
> can use some casting trickery to solve it, but that's not pretty.
>
> Strigi:StreamBase<char>* a = getStream();
> jstream::StreamBase<char>* b = static_cast<jstream::StreamBase<char>*>(a);
> indexStream(b);
>
> We would only need this in the CLucene backend. For other backends
> this is not an issue.

The problem I have with it is that we see the jstreams namespace seep through 
and the kdebase/graphics/etc code has a mix of both namespaces. Which IMO is 
worse then most solutions you can think of :)

I don't pretend to understand the reasons and problems here, but I thought 
that namespaces were meant to avoid this kind of thing in the first place.
Can't we build a layer between the clucene backend and the strigi API to 
isolate anything that happens inside clucene ?
I would find it a bad idea to depend on not one but two external libraries at 
the same time for both binary and source compatibility of our base KDE 
modules.
I can almost guarantee Murphey will come by somewhere in the approx 5 years 
that I guesstimate the KDE4 framework should stay stable.

-- 
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/20070315/1832b9f7/attachment.sig>