attempt to make factory invocation more evident in the code

...but the whole design looks still overengineered. See #388

- should get rid of the explicit specialisation
- always use a function signature and thus have arguments?
- why inheriting from the wrapper?
This commit is contained in:
Fischlurch 2014-09-08 03:37:41 +02:00
parent 21079f3145
commit b2b75fbe43
4 changed files with 26 additions and 9 deletions

View file

@ -53,10 +53,10 @@ namespace lumiera {
/** factory used as dispatcher table
* for resolving typed queries */
typedef MultiFact< Resolution(Goal const&) // nominal signature of fabrication
, Goal::QueryID // select resolution function by kind-of-Query
, BuildRefcountPtr // wrapper: manage result set by smart-ptr
> DispatcherTable; //
typedef MultiFact< Resolution(Goal const&) // nominal signature of fabrication
, Goal::QueryID // select resolution function by kind-of-Query
, BuildRefcountPtr // wrapper: manage result set by smart-ptr
> DispatcherTable; //
/** PImpl of the generic QueryResolver */
struct QueryDispatcher
@ -69,8 +69,8 @@ namespace lumiera {
QID qID = query.getQID();
ENSURE (contains (qID));
return (*this) (qID, query);
} //qID picks the resolution function
return this->invokeFactory (qID, query);
} // qID picks the resolution function
};
@ -103,7 +103,7 @@ namespace lumiera {
void
QueryResolver::installResolutionCase (QID qID, function<Resolution*(Goal const&)> resolutionFun)
QueryResolver::installResolutionCase (QID qID, ResolutionMechanism resolutionFun)
{
ENSURE (!dispatcher_->contains (qID),
"duplicate registration of query resolution function");

View file

@ -125,8 +125,10 @@ namespace lumiera {
virtual bool canHandleQuery (Goal::QueryID const&) const =0;
using ResolutionMechanism = function<Resolution*(Goal const&)>;
void installResolutionCase (Goal::QueryID const&,
function<Resolution*(Goal const&)>);
ResolutionMechanism);
QueryResolver();
};

View file

@ -23,7 +23,7 @@
/** @file multifact-arg.hpp
** Extension allowing the MultiFact to pass arguments to the fabrication.
** This extension is implemented by template specialisations and thus kicks in
** when specifying a function \em signature as factory "product type". The resulting
** when specifying a <i>function signature</i> as factory "product type". The resulting
** factory class exposes a function call operator matching this signature, additionally
** expecting the ID (to select the specific fabrication function) as first parameter.
**
@ -33,6 +33,7 @@
** should yield the product in a form suitable to be accepted by the
** wrapper. E.g., when building smart-ptrs, the fabrication function
** should actually deliver a raw pointer to a heap allocated object.
** @todo still way to convoluted design. We can do better //////////TICKET #388
**
** @see multifact-argument-test.cpp
** @see query-resolver.cpp usage example
@ -115,6 +116,13 @@ namespace lib {
return this->wrap (func(arg));
}
Product
invokeFactory (ID const& id, ARG arg) ///< alias for the function operator
{
return this->operator() (id, arg);
}
};

View file

@ -47,6 +47,7 @@
**
** @note there is an extension header, multifact-arg.hpp, which provides template specialisations
** for the special case when the fabrication functions need additional invocation arguments.
** @todo still way to convoluted design. We can do better //////////TICKET #388
**
** @see multifact-test.cpp
** @see multifact-argument-test.cpp
@ -204,6 +205,12 @@ namespace lib {
return this->wrap (func());
}
Product
invokeFactory (ID const& id) ///< alias for the function operator
{
return this->operator() (id);
}
/** to set up a production line,
* associated with a specific ID