Changes to CodeCompletionWorker regarding multithreading

[Milian Wolff]

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.

> > 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.

For packagers we have to give them some promise for ABI stability. We don't 
have one across 4.x release, but over the lifetime of a single 4.X we have 
one. Not that e.g. PHP + PHP-Docs + other (experimental) plugins also use 
KDevplatform, it's not "just" KDevelop.

So I have to repeat: Sorry, but this change should not go into 4.2, it's sadly 
just too late for that.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110117/03bb4324/attachment.sig>