interfaces / implementations separation (was Let's discuss KDevelop4 interfaces and shell)

[Alexander Dymo]

On Saturday 20 January 2007 11:56, Andras Mantia wrote:
>  I mostly agree with Alexander, with one remark: when it doesn't make
> sense to have alternative implementation, like for the shell or
> pluginloader, I don't see why would we need abstract interfaces and why
> can't we have the code for shell and the others directly in the library
> (platform)? Sure, care has to be taken for BC in those implementations,
> but only in the public interface for them.
Don't get me wrong, I don't want all shell classes to expose interfaces.
Just what's needed for plugins shall be exposed. If we look at
KDevPluginController interface in KDevelop3 we will find quite a lot of
stuff not used by plugins. Also direct 1 shell class - 1 interface
correspondence is not an obligation actually.

We just have to remember, that plugins shall not link to the shell.
Did you see the plugin architecture where plugins link to the shell
that loads them? This kinda defeats the whole purpose of plugins.

>  For this there is a public API for writing plugins (including new
> project managers) and to access some internals of the platform/shell. I
> can't tell right now what needs to be exposed, this will become visible
> only when coding.
Sure, but during KDevelop3 development cycle we had interfaces so we
already know quite a lot about what needs to be exposed. Actually
KDevelop3 interfaces were quite good and allowed us to write lots
of plugins already. So we just have to transfer our existing interface
knowledge to KDevelop4 and add 

> I'm glad that this thread was started now. 
Yes, it is high time we address the issue. We just have to start active 
KDevelop4 development and currently it's not possible because of
broken architecture.