[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Adding ThreadWeaver libraries to kdelibs
From:       Hamish Rodda <rodda () kde ! org>
Date:       2006-09-07 11:24:16
Message-ID: 200609072124.18425.rodda () kde ! org
[Download RAW message or body]


On Thursday 07 September 2006 15:58, Mirko Boehm wrote:
> On Wednesday 06 September 2006 19:01, Simon Hausmann wrote:
> > Job has isFinished() but also bool success(), which looks a bit ugly
> > IMHO. Maybe it would be simpler to have a non-virtual
> > exitStatus()/setExitStatus() property instead of the virtual success
> > function. That's more extensible (with an enum instead of a virtual
> > function that cannot be changed later) and it reads nicely:
>
> Th real issue here is that success is not a generic enough concept to be
> held in a member variable. Most operations that are done in Jobs have a
> natural concept of success. Therefore, a generic setExitStatus method is
> bound to be hard to implement (the state may not even be settable if you
> interface an existing implementation of an operation). Also, an enum is not
> extendable. So possibly it makes sense to simply have success() the way it
> is, and add domain-specific ideas of success to derived job classes. But
> this is definitly open for discussion. Maybe blackarrow can comment on it,
> he seems to use that stuff in kdevelop.

So far, I've had to override success() just to return a member variable, so 
for what I've used, a setExitStatus() scheme would be fine.

I've found that when you want to convey something more than just success or 
failure, you cast to your particular job subclass and interrogate from there.

Cheers,
Hamish.

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]