KIcon API replacement (Re: patches on kcolors)

David Faure faure at kde.org
Sun Mar 25 00:23:35 UTC 2012


On Friday 16 March 2012 00:01:50 Christoph Feck wrote:
> On Thursday 15 March 2012 23:29:49 Kevin Ottens wrote:
> > On Thursday 15 March 2012 21:21:07 David Faure wrote:
> > > On Thursday 15 March 2012 19:53:36 Kevin Ottens wrote:
> > > > Client code would then look like:
> > > > QIcon i = KDE::Icon("foo");
> > > > instead of:
> > > > QIcon i = KDE::loadIcon("foo");
> > > > 
> > > > (I personally think it conveys better the idea as it makes it
> > > > feel almost like a prototype object)
> > > 
> > > Well, it's not so crazy. After I send the mail I thought, icon()
> > > would be better than loadIcon(), especially since the loading
> > > doesn't happen at that point, but on demand.
> > > I was thinking icon() lowercase though, Icon() is a little bit
> > > crazier indeed.
> > 
> > Right icon() would work nicely as well. Breaks less of our customs,
> > but as I pointed I like the "almost prototype object" idea that
> > Icon() would convey.
> > 
> > > But I'm not necessarily against crazy ideas ;-)
> > 
> > Well, I'll let you pick between icon() and Icon() then. ;-)
> 
> I would prefer uppercase "Icon()", because it's not an attribute
> getter, but a factory method for an object of a specific class. Think
> "KDE::Icon" as a class name.

Which will lead people to write 
void setIcon(const KDE::Icon& icon);

So I don't like it. If it's not a class, it's not a class.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list