A simple kdevplatform design question ...

On 21.06.07 17:59:46, Sandro Andrade wrote:
> I'm figuring out the kdevplatform architecture design
and I'm facing a very
> silly question. I hope not to be bothering !
> 
> Why there is a need for separating ICore from Core ?
> 
> We all know the benefits of designing using interfaces
in order to commit to
> an interface, instead of an implementation.
> But I think that, in kdevplatform, it's not supposed to
exist different
> implementations of ICore and I see no flexible factory
code for
> ICore-inherited classes.
> 
> Defining a IPlugin class is perfectly comprehensible
because there will be a
> sort of plugins that need to be handled uniformly.
> 
> What is the design rationale behind the ICore and Core
classes ?

To provide a clean interface that plugins can use. I guess
you didn't
yet read or overread the sentence that state: No code is
allowed to link
to shell directly (except the application executable). Also
you'll
notice that Core has a couple of extra functions like
::initialize() and
*Internal() which are not exposed in the interface because
they are only
allowed to be used inside shell or by main.cpp.

Andreas

-- 
You too can wear a nose mitten.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 6/21/07, Sandro Andrade <sandro.andradegmail.com> wrote:
> Why there is a need for separating ICore from Core ?
As Andreas said, the plugins don't need to link to the
application,
they need to link only to the small library with
well-defined set of
interfaces (with BC guarantees).

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 22.06.07 15:25:32, Sandro Andrade wrote:
> On 6/22/07, Alexander Dymo <dymoukrpost.ua> wrote:
> >
> >On 6/21/07, Sandro Andrade <sandro.andradegmail.com> wrote:
> >> Why there is a need for separating ICore from
Core ?
> >As Andreas said, the plugins don't need to link to
the application,
> >they need to link only to the small library with
well-defined set of
> >interfaces (with BC guarantees).
> 
> As stated in http://accu.or
g/index.php/journals/269, the three main reasons
> for separating interface from implementation are:
> 
> 1) Reducing implementation detail exposed to the user
> 2) Reducing physical coupling
> 3) Allowing customised implementations
> 
> I guess the reason 3) does not apply to the
kdevplatform, right ?

Wrong. It only doesn't apply to the interfaces that are
implemented in
libkdevplatformshell. There are many more interfaces in the
platform.
And those are pure interfaces (as opposed to
partly-implemented
interfaces as IPlugin)

> So, in conclusion, the reason for this programming
style is just to reduce
> compilation time and dependencies ?

No. It is to provide a proper API for plugins. The plugins
don't need
and shouldn't know about certain parts of the API of Core,
Project or
PluginController. And this is a way to force them to do so.
Any plugin
that links against kdevplatformshell is considered broken.

> In despite of these reasons, BC issues
> could be handled by a d-pointer, leading us to forget
about separating ICore
> >from Core ?

Thats not right. A dpointer certainly helps to keep BC,
while being able
to add members and private functions. But the classes in
libkdevplatformshell can even change their public API in
non-BC manner
(adding a virtual, implement a virtual from a base class and
so on)
without any plugin ever noticing, because the plugins don't
work with
ProjectController* but with IProjectController* whose API is
defined and
will not change.

Andreas

-- 
Chicken Little only has to be right once.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel