DataEngine & KPluginFactory

[Kevin Krammer]

On Monday, 2013-07-01, Sebastian Kügler wrote:
> On Monday, July 01, 2013 13:35:27 Kevin Krammer wrote:
> > On Monday, 2013-07-01, Sebastian Kügler wrote:
> > > On Monday, July 01, 2013 09:03:29 Kevin Krammer wrote:
> > > > What if the macro only creates the header content (as its name
> > > > already suggests)?
> > > > 
> > > > name::create() could then be implemented in a plugin specific way,
> > > > not requiring a certain constructor pattern or specifying of
> > > > "baseclass".
> > > 
> > > I'd rather save the user writing that boilerplate.
> > 
> > Hmm, but doesn't the current macro require to write boilerplate code
> > since it  is only applicable for a certain case?
> > 
> > I.e. it requires that objects either have a constructor that matches the
> > expected siganture or require to write the whole plugin factor subclass
> > manually.
> > 
> > A macro that leaves the implementation of the method to the plugin
> > creator allows to share all the boilerplate while also allowing all
> > flexibility on object instance creation.
> > 
> > If it is really necessary to make the one specific use case doable
> > without writing any code I would add a second macro that does this
> > specific implementation.
> > That way the common boilerplate code can be shared by allm those that
> > only every create instance of one object and have the required
> > parent/args constructor just use the second macro in addition.
> 
> Well, the goal, for me, is to make plugin factories work. Right now, we
> only have a handful constructor, and I want to make it possible to build
> those with as little extra hassle as possible -- it means porting all
> plugins, and that's a lot already, even if it's just moving a macro into
> the header file.
> 
> I think we can make arbitrary ctors for plugins possible, but as I said,
> those would then just not use this macro, but supply their own macro that
> does the setup of the KPluginFactory instance.

But wouldn't it be more viable to be able to share the macro for the header 
code part between all plugins instead of having the common parts replicated a 
lot?

I.e. K_PLUGIN_HEADER only creating the header part of the plugin and, if 
really necessary, K_PLUGIN_SOURCE creating one possible implementation for 
create()?

That way K_PLUGIN_HEADER can always be used to create all the boilerplate 
code, K_PLUGIN_SOURCE (or whatever) providing an opt-in convenience for 
certain plugins but not limiting K_PLUGIN_HEADER's universality?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130701/44378857/attachment.sig>