Future of teamwork plugin

[David Nolden]

Am Mittwoch, 4. Juli 2007 15:39:28 schrieb Kris Wong:
> times, and it is quite a bitch to try to follow. The main problem in this
> code is all of the implicit casts.  It's nearly impossible to try to follow
> code when different types "automagically" convert themselves to other
> types.  Very rarely does this practice make sense (some examples might be a

In the teamwork-plugin, there is only implicit casts where it is c++-logical. 
That means that a shared-pointer is implicitly casted to a normal pointer, 
and a shared-pointer can be casted to any parent-class shared-pointer.
I think the only addition to that is the locking-cast.

You're right about kdevelop-3.4 and the implicit casts in the cc-code. There 
is a very simple reason for that though: When I started working on the 
code-completion there, it already had some quite complicated algorithms in 
it, and everything worked with QString's and QStringLists. Since I didn't 
plan to rewrite most of it, I simply added some more "intelligent" classes 
that seamlessly integrated into the already available code. That especially 
ment that they could be implicitly casted to their old, stupider, versions.

So that's mainly a result of the evolution the code has made. :-)
Of course having that many implicit casts later lowered the constraint to add 
more of them.

greetings, David