Adding new 'virtual' methods to KCalendarSystem

Oswald Buddenhagen ossi at
Sun Jan 3 00:02:25 GMT 2010

On Sat, Jan 02, 2010 at 11:17:53PM +0000, John Layt wrote:
> I was wondering if instead I could add the virtual methods to the d-pointer 
> instead and have each child class override that as required?
yes. qt does that in several places.

> Would it be a bad idea to make the derived classes friends of the base
> to directly access the d-pointer, which might be needed anyway?
qt employs the "protected shared d" technique to save memory
allocations. i also used it in kty/-device.
of course, this isn't particularly OO, either. ;)

> An alternative is to just do all the new implementations in the base
> class and have an if-else-if tree based on calendarType(), but that
> isn't very OO.
that's the last resort.

> Or is there another better way?
non-qobject-based classes should all have a virtual_hook (see kconfig*)
- failure to have it is, uhm, sloppiness. :-P
though this is utterly ugly, so it should be only used for methods
which must be virtual outside the lib, i.e., where the shared d trick
doesn't work.

More information about the kde-core-devel mailing list