REMINDER: Final review of VCS interfaces

[Andreas Pakulat]

On 01.06.07 17:58:36, Robert Gruber wrote:
> 
> On Sun, 27 May 2007 11:48:22 Andreas Pakulat wrote:
> >> I'm still not sure about returning VcsJob anyways. For example in cvs
> >> plugin I'm using my own CvsJob class which is derived from KJob and therefore
> >> already provides all that stuff from VcsJob. So why don't we just return a
> >> KJob pointer? Or maybe derive VcsJob from KJob, which will make the start
> >> and cancel slots and the signals needless as they are already provided by
> >> KJob.
> > 
> > Because KJob doesn't provide an API that is usable. VcsJob should either
> > be a pure interface which you inherit from additionally to KJob or it
> > should be a KJob subclass. I'm not sure which approach is better, didn't
> > really look into that yet (but I'm guessing the second one)
> 
> Deriving CvsJob from both our VcsJob interface-class and KJob isn't possible. 
> 
> You cannot inherit from two QObject subclasses:
> [ 35%] Generating cvsjob.moc
> /home/kdedev/src/kdevelop/lib/plugins/vcs/cvs/cvsjob.h:87: Warning: Class CvsJob inherits from two QObject subclasses VcsJob and KJob. This is not supported!
> 
> So I also vote for deriving VcsJob from KJob.

Apart from the fact that I wanted to do that anyway: Why is VcsJob a
QObject subclass? Who added that? I guess thats local on your hdd right
(its not in svn). The class doesn't have any parent, even though it uses
the signals and slots macros. These two expand simply to nothing and
protected (signals) and we use the same means in extension interfaces to
tell users of the API that these signals and slots are available, even
though they are only defined on the subclass (i.e. CvsJob).

Andreas
 
-- 
Try to have as good a life as you can under the circumstances.