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

[Andreas Pakulat]

On 19.01.07 16:30:06, Alexander Dymo wrote:
> Ok, Matt is right I indeed need to provide the reasoning for 
> interfaces/implementations separation.
> 
> What do I mean when I talk about interfaces:
> - interfaces should be abstract classes (whenever possible)
>   which will expose only essential parts of KDevelop core functionality

In general I'm with you here, however having tried to write an RCP app
with eclipse I also want to see this stopping at some point. Eclipse is
pretty much overengineered in this regard, everything in eclipse uses
only interfaces and they're not that well documented. Which means one
has to dig into the sources, which are hard to find too.

> 2) abstract, minimal, clean and independent interfaces would:
> - make it easier for new developers to approach KDevelop4 development
>   and understand the architecture

More important than having interface/impl separation is really, really
good documentation for the API. The KDev3 API is underdocumented,
although its not as bad as with some other API's I've read. Its also
important to document all corner-cases in the API, like the method
"result" might differ for certain combinations of the parameters. Or if
certain combo's are completely ignored (this is the kind of things that
turn newcomers away, they try something and it doesn't work, but nowhere
is explained that it can't work)

> 3) abstract, minimal, clean and independent interfaces would:
> - allow us to not care about BC in the shell
> 	Our "shell" (read implementation of a plugin loader, project loader,
> 	main window stuff) should not be kept BC. Shell is evolving target
> 	and keeping BC there would make it harder to improve KDevelop.

I'm not sure I have fully understood all aspects of keeping BC, but I
think the goal is that the shell is part of the platform, so for
instance Quanta doesn't need to provide its own shell. In that case, why
don't we need to keep BC in the shell? If Quanta uses the shell it
surely isn't good if its ABI changes. 

Or would this approach allow the shell to have a couple of interface
implementation classes which only provide the same API as the interfaces
define and everything else wouldn't even be exposed in terms of symbols
in the library?

> What I don't want our interfaces to do:
> 1) I don't want our interfaces to allow to implement another version of
>   a platform. Nobody will do that and nobody needs that.

I totally agree with you here, there's no point in re-inventing the
platform if the existing one works good.

> What I want our interfaces to be:
> 1) The entry point to understanding KDevelop architecture
> 2) The clear set of things all platform plugins can use/call/access/whatever.

One problem we might face here, especially with BC in mind, is that we
need to define _now_ what we allow for plugins to use and I'm not so
sure we don't want to change that in the future (before KDevelop5). But
maybe you "older" devs have a clearer view about that than I have. I
certainly don't know for sure if the current API for our importers is
enough or if we need more stuff there...

Andreas

-- 
Are you sure the back door is locked?