[Bug 29451] Too many asynchronous setup steps needed for basic usage

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29451

--- Comment #16 from Olli Salli <ollisal at gmail.com> 2010-08-18 10:59:54 PDT ---
(In reply to comment #13)
> 
> I think we're confusing two things. I'd like to have the AccountFactory,
> ConnectionFactory, ChannelFactory objects etc be non-subclassable objects
> created by the AM / Account / Client - not a subclass supplied from the
> application.
> 
> The subclass selection mechanism would then be setConstructorFunction() or
> alike on said Factory object - C++ makes creating such constructor functions
> eg. as template specifications functions sufficiently easy (much less
> boilerplate than having a custom Factory subclass just to get new
> YourFavoriteTypeHere).
> 
> That said, I think the setDesiredFeatures() methods should also live on said
> *Factory objects, mostly because of how ChannelFactory would work - you specify
> a constructor function per set of immutable Channel properties, so you'll also
> want to keep specifying desired features for a set of immutable properties at
> the same place. For consistency, I'd do this for all of the factories, even if
> what they construct doesn't depend on anything in the corresponding D-Bus
> object at all (always the same subclass and same features).
> 

Agreed with Andre over IRC that the Factory objects should be passed to the
Account / AM / AbstractClient constructors, and not changed afterwards, and
they should essentially just be tuples of (subclass to construct, list of
features to request).

So we'll need new constructors for them, but should retain the old ones for
backwards compat/convenience. The old ones should pass (base class, no
features) (except for Account, for which core should be passed) for all to
preserve semantics. Also, I believe we should make them "backwards" with
default arguments, a bit like:
AbstractClient::AbstractClient(Other arguments, const ChannelFactory &chanF =
ChannelFactory::theOneWithTpQt4StockSubClassesAndNoFeatures(), const
ConnectionFactory &connF =
ConnectionFactory::theOneWithTpConnectionAndNoFeatures(), const AccountFactory
&accF = AccountFactory::theOneWithTpAccountAndCore())
because probably the smallest level (first here) is tampered with first. This
also necessitates adding all three as empty stubs even if we start the
implementation from just one of them in a branch as I believe we should.

Afterwards, the factories should be accessible with a const accessor to prevent
further tampering. We CAN add mutating API later on though, if needed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.