Changes to CodeCompletionWorker regarding multithreading

[David Nolden]

2011/1/17 Andreas Pakulat <apaku at gmx.de>:
> Thats exactly the attitude that makes the situation stay as it is and
> why the libraries in kdevplatform are still not used by any project
> except kdevelop.

Anyone could simply fork. The problem is that kdevplatform simply
isn't there yet.

Furthermore, most of the code is not designed to be a library. When
you design a library, you have to carefully think about the _future_
needs, and design the interfaces so that they are flexible and can
stay stable. However much of the code is written with only the
_current_ needs in mind, in order to fix a specific current issue. For
example much of the code completion code was just designed by me as an
implementation detail. However then others took the code, ripped it
apart at more or less random boundaries that fitted the specific
difference between C++ and php, and then these boundaries became
interfaces. Forcing such interfaces to stay stable would either cause
I huge amount of needless effort in the future, or it would simply
reduce the quality of the application. For example, if we would
enforce binary compatibility already now, my only options regarding
fixing this issue would be either simply not doing it (lower app
quality), or writing an alternative code-completion interface and
maintaining both in the future (needless effort, uglier codebase).

> Apart from that, a change that has unknown side-effects in a stable
> release is IMHO just a no-go. Nobody forces us to wait 6 months or more
> for the next release if that is your concern. Its also not a regression,
> there's been no release with multi-threaded code-completion.

Any change may have unknown side effects. Anyway I am not arguing that
this change should go in, only that binary compatibility should not be
a concern, since we don't enforce it anyway.

Greetings, David