From kde-pim  Sat Oct 06 22:57:01 2007
From: David Jarvie <lists () astrojar ! org ! uk>
Date: Sat, 06 Oct 2007 22:57:01 +0000
To: kde-pim
Subject: Re: [Kde-pim] KPIMIdentities::IdentityManager deprecated methods
Message-Id: <200710062357.01745.lists () astrojar ! org ! uk>
X-MARC-Message: https://marc.info/?l=kde-pim&m=119171145826294

On Saturday 06 October 2007 23:33:42 Ingo Klöcker wrote:
> On Saturday 06 October 2007, David Jarvie wrote:
> > On Friday 05 October 2007 00:35:49 Ingo Klöcker wrote:
> > > On Thursday 04 October 2007 01:43, David Jarvie wrote:
> > > > KPIMIdentities::IdentityManager::identityForName() is deprecated
> > > > (and apparently has been for a long time). What method should be
> > > > used instead?
> > >
> > > KPIMIdentities::IdentityManager::identityForUoid()
> > >
> > > The name of an identity can be changed by the user but the
> > > numerical ID will always stay the same. Therefore identities should
> > > always be identified by their ID and never by their name.
> >
> > I've now marked this and 3 other methods as KDE_DEPRECATED. But I
> > think that KPIMIdentities::IdentityManager::identityForName() is
> > actually necessary, since there are circumstances when it is
> > reasonable to convert from a name to a uoid - for example, when
> > converting old config files. Perhaps a better solution would be to
> > add a new method IdentityManager::uoidForIdentityName(). This would
> > allow for the case I mention, without being quite so tempting to use
> > in deprecated ways.
> >
> > This would be best added by tomorrow if possible, to be in time for
> > the KDE development system tagging.
> >
> > Do you agree?
>
> No, I object to adding this method. As you said it is only needed for
> upgrading old config files. Nobody should assume that identities can be
> identified by their name and therefore IMO we shouldn't make it too
> easy to get the identity belonging to a certain name. If somebody still
> wants to do this (e.g. for upgrading) then he can simply iterate over
> all identities.
>
> BTW, upgrading old config files will probably anyway be done by some
> perl scripts or some special-purpose minimal KDE apps which shouldn't
> use the deprecated methods so that they will still work after the
> methods have been removed. So I don't see a reason to keep those
> deprecated methods (which are deprecated since several version of KDE
> 3.x). But I guess now it's too late to remove them. :-( I really hope
> we don't have to support this cruft until KDE 5.

OK, I accept your reasoning.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/