proposed KAction/KActionCollection API changes

[Ellis Whitehead]

Hi Thomas,

> So, for the same reason you would choose a normal indenting style and readable
> variable names, you should focus on using simpler constructors. With that I
> mean both shorter (less arguments) constructors and less choice of different
> constructors.

This is a good principle, but in this case it conflicts with another
important principle: trying to minimize lines of code.  So how do the
conflicting principles balance out?  99% percent of the time, I'd say
that your "simple constructors" argument has the advantage.  The 1%
where the scale tips in the other direction is when it's common to
instantiate masses of a particular object.
With KAction, we have such a situation.  A larger program can easily
have around 100 actions, and it's not uncommon to see 20 actions
declared in a single function.  For that reason, the *possibility* for
conciseness takes on a much more important role than it does for
toolbars, for instance.

I don't think that this is an issue that will make or break KDE of
course *grin*, but I also don't think that eliminating the long
constructors for KAction is the appropriate design decision.

> Based on working with people that try to focus on _their_ piece of the
> software I think you are looking from the perspective of someone that is too
> familiar with the different constructors.

Well, I won't disagree with that, though I don't think it entirely
describes the situation either.  As an unrelated historical note, my
original reason for not having shorter constructors was to ensure that
the object was fully initialized, which a) made the KAction/KAccel/etc
code simpler and b) prevented a couple programmer pitfalls.

> From the perspective of people that don't want to learn kaction constructor
> order from memory, that way is actually harder to write and maintain, and
> most certainly harder to read.

For the reasons you say, I'm in favor of also having the QAction-like
constructors.  But your assertion is only true when the programmer
only creates a couple instances.  The *opposite* is true if they
create a dozen of them, one after the other.


Best regards,
Ellis


On 1/3/07, Thomas Zander <zander at kde.org> wrote:
> On Wednesday 03 January 2007 00:21, Ellis Whitehead wrote:
> > > 1) KAction and its subclasses get the same 3 (compatible) constructors...
> > > 2) Actions need to be explicitly added to the actioncollection...
> >
> > For a long list of actions, I still find the table-like actions lists
> > like in Olivier email *much much* easier to read than 3 or 4 lines of
> > code per action. I personally wouldn't be want to lose the
> > possibility for these concise definitions.
>
> Based on working with people that try to focus on _their_ piece of the
> software I think you are looking from the perspective of someone that is too
> familiar with the different constructors.
> From the perspective of people that don't want to learn kaction constructor
> order from memory, that way is actually harder to write and maintain, and
> most certainly harder to read.
>
> So, for the same reason you would choose a normal indenting style and readable
> variable names, you should focus on using simpler constructors. With that I
> mean both shorter (less arguments) constructors and less choice of different
> constructors.
>
> --
> Thomas Zander
>
>
>