Adding new 'virtual' methods to KCalendarSystem

[John Layt]

On Sunday 03 January 2010 00:02:25 Oswald Buddenhagen wrote:
> On Sat, Jan 02, 2010 at 11:17:53PM +0000, John Layt wrote:
> > 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. ;)

Thanks, I've been reading up in TechBase on that and it looks to fit the bill, 
see http://techbase.kde.org/Policies/Library_Code_Policy#Shared_D-Pointers and 
http://techbase.kde.org/Policies/Library_Code_Policy/Shared_D-Pointer_Example

I do have a couple of questions about implementing this in the existing code.

If existing code looks as follows:

    class KFooBase
    {
    private:
        KFooBasePrivate * const d;
    };

    class KFooBasePrivate
    {
    };

    class KFooDerived : public KFooBase
    {
    private:
        KFooDerivedPrivate * const d;
    };

    class KFooDerivedPrivate
    {
    };

then can modified code look like:

    class KFooBase
    {
    private:
        friend class KFooDerived;
        KFooBasePrivate * const d_ptr;
        Q_DECLARE_PRIVATE( KFooBase );
    };

    class KFooPrivate
    {
    };

    class KFooDerived : public KFooBase
    {
    private:
        Q_DECLARE_PRIVATE( KFooDerived );
        KFooDerivedPrivate * const dont_use;
    };

    class KFooDerivedPrivate : KFooBasePrivate
    {
    };

Is it OK to re-purpose the existing declared private classes by now deriving 
them from the base private, or would changing their class hierarchy break BC?  
My thinking is this is safe.

Will the Q_DECLARE_PRIVATE use in KFooDerived clash with the one in KFooBase 
due to the friend?  I'm thinking it is not even necessary in the base where I 
could use d_ptr directly without needing  a cast?

> non-qobject-based classes should all have a virtual_hook (see kconfig*)
> - failure to have it is, uhm, sloppiness. :-P

The problems of an aging code base and an inexperienced coder :-)  I'll make a 
KDE5 note to add one.

Cheers!

John.