Adding new 'virtual' methods to KCalendarSystem

[John Layt]

Hi,

In KCalendarSystem most methods are virtual to allow each calendar 
implementation to override with their particular calculations as required.  I 
need to add more virtual methods to support new features like Era-based 
calendars.  

The problem is there are no extra slots reserved in the virtual table, and the 
base class is not based on QObject so I can't use the slot trick described on 
TechBase.

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?

I was thinking it would look something like this:

// Base class

class CalBase
{
public:
    CalBase();
    virtual int calcFoo( int y, int m, int d );  // already exists
    int calcBar( int y, int m, int d );  // new 'virtual' method
protected:
    setBaseDpointer( CalBasePrivate * );  // new method
private:
    CalBasePrivate * const d;  // already exists
}

CalBase::CalBase()
{
    // No longer create base d-pointer here
}

int CalBase::calcBar( int y, int m, int d )
{
    return d->calcBar();
}

// Implementation of CalBasePrivate add new virtual method

class CalBasePrivate
{
    virtual int calcBar();  // new virtual method
}

int CalBasePrivate::calcBar( int y, int m, int d )
{
    return y + m + d;
}

// Implementation of CalX, no changes in header

CalX::CalX() : CalBase()
{
    setBaseDpointer( new CalXBasePrivate() ); // new
}

// Implementation of CalXBasePrivate, extends CalBasePrivate

class CalXBasePrivate :: CalBasePrivate
{
    virtual int calcBar();  // new virtual method
}

int CalXBasePrivate::calcBar( int y, int m, int d )
{
    return y * m - d;
}


Would this work?  Are there any problems with doing this besides performance?  
I'm assuming adding more virtual methods to the d-pointer would not break BIC?  
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?

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.

Or is there another better way?

Cheers!

John.