[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: klibfactory cleanup
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-09-25 8:36:53
[Download RAW message or body]

On Mon, Sep 24, 2001 at 09:46:14PM +0200, Bernd Gehrmann wrote:
> On Mon, 24 Sep 2001, Simon Hausmann wrote:
> > On Mon, Sep 24, 2001 at 08:52:22PM +0200, Bernd Gehrmann wrote:
> > > On Mon, 24 Sep 2001, Simon Hausmann wrote:
> > > > 
> > > > Unless there are further objections I'll add your KDE_EXPORT_COMPONENT_FACTORY macro 
> > > > with two arguments to kcomponentfactory.h then (after renaming KLibFactory to 
> > > > KComponentFactory - unless someone objects against it :)
> > > 
> > > I don't see the point. KLibFactory doesn't produce components (which would
> > > mean return type QUnknownInterface), it produces QObjects. The notion of a
> > > component is very precisely defined in the Qt documentation, so you
> > > certainly do not help someone learning the API when you overload a term
> > > with an additional meaning.
> > 
> > The recent qt snapshots show that QCom has been made private API. And I
> > indeed speak of QObjects as components from which you can query pure interfaces
> > for example using rtti ;)
> 
> Maybe I'm missing something, but I don't think that reduces the confusion.
> Dynamically loaded QObjects in the latest rsync snapshots are called
> 'Plugin', not 'Component'. This is even consistent with KParts::Plugin,
> which is derived from QObjects :-)

How else would you call the 'objects' a KLibFactory creates, other than
components? :-) (plain other than plain objects...well, yes, KObjectFactory
we could name it... but that's less buzz-wordy >;-)

QComponentFactory (the now private one) for example does create components,
indeed, but it does not return a reference to the actual component. All you
get is an interface (that being the whole point about (q)com, you never really
see the component behind but only talk to interfaces and jump from one to the 
other) .

I believe the naming of a component factory for KLibFactory is correct because
the objects it creates and returns (directly) are components in their best
meaning, no? You don't really get an abstract interface or something similar
from the factory. 

But I might be missing something

Simon

[prev in list] [next in list] [prev in thread] [next in thread]