Nepomuk + kdelibs + BC

[Sebastian Trüg]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs-nepomuk-qurl.diff
Type: text/x-diff
Size: 4481 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080111/e35d7238/attachment.diff>