proposed KAction/KActionCollection API changes
ogoffart at kde.org
Wed Jan 3 14:06:38 GMT 2007
Le mercredi 3 janvier 2007 13:29, Tobias Koenig a écrit :
> On Wed, Jan 03, 2007 at 01:00:27PM +0100, Olivier Goffart wrote:
> > Le mercredi 3 janvier 2007 12:23, Kevin Ottens a écrit :
> Hi Olivier,
> > > That's where I disagree, for someone knowing by heart all the methods
> > > this kind of table might help. Otherwise you'll probably wonder about
> > > the role of each parameter. Hence why IMO it's harder to maintain and
> > > read.
> > the i18n( ... ) , KIcon( ... ) , SLOT( ... ) are great hints which make
> > the role of parameters quite expressive
> Right, but you have to remember the order of the arguments, so it's hard
> to write a ctor without taking a look at the API docs.
But if the developper prefer he can use the short constructor and all the set.
The long constructor is there just for convenience.
And to help to remember the order, some editor do great work with
Also, when you add an action, in general you add it in a function which has
already ten others action declaration, so you just look one line before to
have the model :-)
> Matthias gave a nice presentation about API design at Akademy 2004 in
> Ludwigsburg where he discussed the pro and cons of ctors with many
> arguments, its worth a read as well.
I've read that.
I know that the short constructor are *in general* good for readability.
But no rules is always 100% true.
In the case of KAction, I think this is the exception
that's why i suggest
KActionCollection::newAction(const char* name,
const QString& text=QString(),
const KIcon& icon=KIcon(),
const QObject* receiver=0, const chat* slot=0)
Ok, that's 5 arguments.
But considered the fact that it will appears dozens of time in a function, i
think it's worth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel