On Sat, Nov 17, 2001 at 12:24:52PM -0500, Ellis Whitehead wrote:
> On Saturday 17 November 2001 15:29, Simon Hausmann wrote:
> > A possibly stupid question, but why does KAccel no more inherit from
> > QAccel, and why does it aggregate KAccelBase instead of inheriting
> > from it?
> 
> 1) to lighten up the includes.
> 2) to reduce re-compilation requirements.
> 
> kaccelbase.h is 'heavy', and I'll still be modifying it a lot before 3.0 is 
> released.  If KAccel inherited from KAccelBase, then everything which 
> includes kaccel.h (a _lot_) would want to be recompiled for each 
> modification.  That was a major time waster for me in the 2.2 cycle.

[ as long as the change is binary compatible (which it has to be
after 3.0) it doesn't really matter, does it? -- I mean, it's a bit
like API oddness versus compilation time ;-) ]

> > ( blah->basePtr()->foo() looks like an odd API to me... )
> Even as it is now, few programmers would ever see this side of the API.  I 
> will be creating a few more wrapper functions, but the basePtr() use is 
> mostly restricted to places where relatively 'unusual' things are done (such 
> as removing an accelerator from the set).

Well, everything listed in the header they see, and they'll get
confused about a 'basePtr()' method, where there is no docu and where
the name says nothing about the purpose of the function. 

(that in turn might scare them off and ignore the method, but IMHO
that's bad practise)

If you want to hide the functionality from KAccelBase then you could
inherit from it in a protected or even private way, maybe?

A question about the KAccel-does-not-inherit-from-QAccel-anymore change: 
Is it because the new KAccel works fundamentally different than
QAccel? 

(although it confuses me that the very first thing KAccel internally does 
is creating a new QAccel instance)


Simon

P.S.: sorry for the rants/questions :-} -- independant from what I
      wrote above I really like the stuff you're doing, especially 
      the emacs-like shortcut support :)