Changes to CodeCompletionWorker regarding multithreading

[David Nolden]

2011/1/17 Milian Wolff <mail at milianw.de>:
> David Nolden, 17.01.2011:
>> 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.
>
> While this is true, it does not mean that we should hence break ABI whenever
> we want. Instead we should concentrate on making the API reusable in master.
>
>> 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).
>
>
> You misunderstood. We only have an ABI-promise starting with the first RC
> release and then over the lifetime of a 4.X release. Nothing stops you from
> breaking ABI and cleaning up the API in master.

Ok. Anyway I just wanted to make clear that with the current state of
the interfaces (at least in kdevplatform/language), binary
compatibility is not discussable. Furthermore, considering the bugs
we're still fighting with, and the absence of tests etc, I think there
are much more important areas that we should invest our energy into,
than trying to design the "perfect" interface.

Anyway the whole concept of binary compatibility, even in kdelibs,
seems superseeded to me. The only applications that profit from binary
compatibility are closed-source apps. Yes I understand that the idea
is that KDE becomes an ecosystem for closed- AND open-source apps, but
the reality after 3 years of KDE4 looks very different, and it doesn't
make the slightest sense to hinder the development just to help an
audience which doesn't even exist. For open-source, source
compatibility is completely enough. When the distribution is using a
decent build-system, then it makes absolutely no difference for them
(see opensuse build-service).

Greetings, David