Adding new 'virtual' methods to KCalendarSystem
Oswald Buddenhagen
ossi at kde.org
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