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

[Matt Rogers]

On Friday 19 January 2007 9:51 am, Andreas Pakulat wrote:
> 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...

Well, if we start small, we can always add later. We just can't take away.

-- 
Matt