Nepomuk + kdelibs + BC

[Allen Winter]

On Friday 11 January 2008 03:13:53 Sebastian Trüg wrote:
> On Friday 11 January 2008 08:50:50 Sebastian Trüg wrote:
> > On Friday 11 January 2008 00:54:21 Michael Pyne wrote:
> > > On Thursday 10 January 2008, Allen Winter wrote:
> > > > On Thursday 10 January 2008 04:07:44 Sebastian Trüg wrote:
> > > > > Hi guys,
> > > > >
> > > > > is it ok for me to do a little binary comp breakage in
> > > > > kdelibs/nepomuk for KDE 4.1. I want to change the API of some
> > > > > classes (which are so far only used by me AFAIK) to match the
> > > > > general QT/KDE design, make them faster and cleaner.
> > > > >
> > > > > Any objections for me to do that?
> > > >
> > > > Could you post a patch?
> > > >
> > > > How about  creating new methods and deprecating the old?
> > >
> > > I don't like the idea of breaking BC.  But since Nepomuk is it's own
> > > .so it's at least something that packagers can work around by having a
> > > libnepomuk-40 type package for KDE 4.0 applications.
> > >
> > > How does changing all the return types affect source compatibility
> > > though? Can a one-off application written against 4.0.2 compile against
> > > 4.1?
> >
> > I thought about it and I can keep Nepomuk::Resource BC by simply
> > introducing new constructors and marking the old deprecated. I will then
> > leave the return types as is. It is not as pretty but not that big a
> > deal.
> >
> > As for the other patch, Nepomuk::Class and Nepouk::Property: I could move
> > the new classes to some new namespace like Nepomuk::Types and then make
> > the old classes just deprecated wrappers around the new ones, thus
> > staying BC, too.
> >
> > How about that?
> > I know it is problematic but I did not think of this improvement before.
> > it just came to me last week. :( And it really makes a difference in
> > performance and handling.
> >
> > Cheers,
> > Sebastian
>
> Please find attached a non-BC-breaking patch to Nepomuk::Resource.

Seems fine to me now.