REMINDER: Final review of VCS interfaces

Andreas Pakulat apaku at gmx.de
Mon May 28 18:48:12 UTC 2007


On 28.05.07 13:54:40, dukju ahn wrote:
> > > > I knew somebody would ask right after I sent the mail :) The thing is
> > > > that KJob only provides means to start/kill/resume the job. VcsJob adds
> > > > a few things on top of that (type, results, common finished signal)
> > >
> > > That still doesn't stop us from deriving from KJob, in fact, it's the perfect
> > > case for building on top of it. Am I right, or do I miss something?
> >
> > Well, its not much that VcsJob can do itself, basically each plugin has
> > to create its own vcsjob subclass and do a proper implementation. All
> > that VcsJob can do is implement cancel() and kall KJob::kill() and then
> > plugins *job subclass would implement doKill(). So I'm not sure having
> > that one method implemented justifies a KJob subclass.
> 
> That's not true. Many methods are duplicated with KJob
> Kjob provides finished(KJob) signal, removing the need of
> void VcsJob::finished( VcsJob*, FinishStatus );

finished is an internal signal, so we can't use that. Also the API docs
are incomplete, there are at least 3 signals not documented which is why
I didn't see a reason to derive from KJob. Still our finished() signal
provides means to directly know wether a job was finished, cancelled or
an error occured. KJob doesn't allow to know wether cancel happened or
not.

> It also provides errorString(), which eliminate the need of
> VcsJob::errorMessage();

Right, but thats just a name.

> Moreover the name of VcsJob::start() and exec() are same with
> Kjob::start() or exec(). Plugins' *Job classes will get trouble when they
> double-inherit KJob and VcsJob.

No they won't. start and exec are pure virtual functions, that doesn't
cause any trouble when you subclass from both KJob and VcsJob. Also
having the same methods is by purpose here.

> Just subclass Kjob and make other methods, such as type(), fetch()
> , pure virtual. Any objection?

Not from me, but please keep the finished signal as well as the
cancel slot.

Andreas

-- 
Just because the message may never be received does not mean it is
not worth sending.




More information about the KDevelop-devel mailing list