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);
> 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
I can almost guarantee Murphey will come by somewhere in the approx 5 years
that I guesstimate the KDE4 framework should stay stable.