fragile ctor (Re: KInstance redesign)

[Matthias Kretz]

On Friday 19 January 2007 14:24, David Faure wrote:
> On Friday 19 January 2007 13:15, Matthias Kretz wrote:
> > - The ctor that takes (const QByteArray &instanceName) could look at the
> > current objects whether one with that name exists and return that one
> > (that means you can identify a component using either the instanceName or
> > the KInstance/KComponentData object).
>
> I don't think we need that, do we? The kde3 shows that we can always pass
> it around (and the refcounting will definitely help, see below), so why
> would we need to use fragile lookup-by-name code? Fragile because you could
> pass any string even if doesn't mean anything, which sort of lacks
> type-safety in a way (a KComponentData is component data, "foobar" isn't
> necessarily an existing component name). Do you have an example in mind
> where two pieces of code would both know the component name and yet not
> have access to the componentdata directly?

I've come across many KCModules that want to use one KInstance object for 
multiple KCModule objects. When porting those to use 
K_EXPORT_COMPONENT_FACTORY properly I had the idea of adding the feature I 
mentioned above. KGenericFactory can create a KInstance object for you if you 
pass an instanceName or KAboutData object. Now each KCM has its own Factory 
but we want to have only one KInstance object. It would be convenient if the 
factories return the same KInstance if the instanceName passed to the factory 
is the same. The less convenient solution is to reimplement 
KGenericFactory::createInstance().

I agree that adding said behaviour to KComponentData would not win a prize for 
beauty. :) And I'm currently leaning more towards requiring those modules to 
reimplement createInstance()...

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070119/142d788d/attachment.sig>