WIP Query<TY> implementation draft...

This commit is contained in:
Fischlurch 2009-10-24 00:23:22 +02:00
parent 455ad14ae5
commit c3441ac26a
4 changed files with 171 additions and 33 deletions

View file

@ -146,7 +146,7 @@ namespace lib {
/**
* Convenience shortcut for automatically setting up
* a production line, fabricating a singleton instance
* of the given target type (TAR)
* of the given target type (IMP)
*/
template<class IMP>
class Singleton

View file

@ -0,0 +1,53 @@
/*
QueryResolver - interface for discovering contents of a scope
Copyright (C) Lumiera.org
2009, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
#include "proc/mobject/session/query-resolver.hpp"
//#include "proc/mobject/session/track.hpp"
//#include "proc/mobject/placement.hpp"
//#include "proc/mobject/session/mobjectfactory.hpp"
//#include "proc/asset/track.hpp"
namespace mobject {
namespace session {
QueryResolver::~QueryResolver() { }
/** TODO??? */
void
QueryResolver::issue (Goal& query)
{
if (!canHandleQuery (query.getQID()))
throw lumiera::error::Invalid ("unable to resolve this kind of query"); ////TICKET #197
UNIMPLEMENTED ("dispatch-mechanism for re-discovering specific type-context");
}
}} // namespace mobject::session

View file

@ -26,7 +26,9 @@
//#include "proc/mobject/mobject.hpp"
//#include "proc/mobject/placement.hpp"
#include "lib/typed-counter.hpp"
#include "lib/iter-adapter.hpp"
#include "lib/util.hpp"
//#include <vector>
//#include <string>
@ -37,37 +39,104 @@
namespace mobject {
namespace session {
class Scope;
using util::unConst;
// class Scope;
class QueryResolver;
/**
* TODO type comment
* Query ABC
*/
template<class MO> ///////////////////////TODO: can we get rid of that type parameter? in conjunction with the virtual functions, it causes template code bloat
class Query
class Goal
{
public:
virtual ~Query() {}
virtual ~Goal() {}
/* results retrieval */
enum Kind
{ GENERIC = 0
, DISCOVERY
};
typedef MO* Cur;
typedef lib::IterAdapter<Cur,Query> iterator;
struct QueryID
{
Kind kind;
size_t type;
};
iterator operator()(){ return this->runQuery(); }
QueryID getQID() { return id_; }
static bool hasNext (const Query* thisQuery, Cur& pos) { return thisQuery->isValid(pos); }
static void iterNext (const Query* thisQuery, Cur& pos) { pos = thisQuery->nextResult(); }
/* diagnostics */
static size_t query_cnt();
class Result
{
void *cur_;
protected:
template<typename RES>
RES& access()
{
REQUIRE (cur_);
return *reinterpret_cast<RES*> (cur_);
}
};
static bool hasNext (const Goal* thisQuery, Result& pos) { return unConst(thisQuery)->isValid(pos); } ////TICKET #375
static void iterNext (const Goal* thisQuery, Result& pos) { return unConst(thisQuery)->nextResult(pos);}
protected:
virtual iterator runQuery() =0;
QueryID id_;
Goal (QueryID qid)
: id_(quid)
{ }
/* iteration control */
virtual bool isValid (Cur& pos) const =0;
virtual Cur const& nextResult() const =0;
virtual bool isValid (Result& pos) =0; /////TODO danger of template bloat?
virtual Result const& nextResult(Result& pos) =0;
};
/** Context used for generating type-IDs to denote
* the specific result types of issued queries */
typedef lib::TypedContext<Goal::Result> ResultType;
/**
* TODO type comment
* Concrete query to yield specifically typed result elements
*/
template<class RES>
class Query
: public Goal
{
static QueryID
defineQueryTypeID ()
{
QueryID id = {Goal::GENERIC, ResultType::ID<RES>::get()};
return id;
}
public:
Query()
: Goal (defineQueryTypeID())
{ }
/* results retrieval */
class Cursor : public Goal::Result
{
public:
RES& operator* () { return access<RES>(); }
RES* operator->() { return & access<RES>(); }
};
typedef lib::IterAdapter<Cursor,Goal> iterator;
operator iterator() ;
iterator operator() (QueryResolver const& resolver);
};
@ -79,26 +148,42 @@ namespace session {
public:
virtual ~QueryResolver() {}
virtual ~QueryResolver() ;
/** issue a query to retrieve contents
* @param scope or container on which to discover contents
* @return an iterator to yield all elements of suitable type
*
* @todo doesn't this create a circular dependency? scope indirectly relies on QueryResolver, right??
* The query is handed over internally to a suitable resolver implementation.
* After returning, results can be obtained from the query by iteration.
* @throw lumiera::Error subclass if query evaluation flounders.
* This might be broken logic, invalid input, misconfiguration
* or failure of an external facility used for resolution.
* @note a query may yield no results, in which case the iterator is empty.
*/
template<class RES>
typename Query<RES>::iterator
query (Scope const& scope)
{
UNIMPLEMENTED ("create a specific contents query to enumerate contents of scope");
}
void issue (Goal& query);
protected:
virtual bool canHandleQuery (Goal::QueryID qID) const =0;
};
///////////////////////////TODO currently just fleshing the API
template<typename RES>
inline typename Query<RES>::iterator
Query<RES>::operator() (QueryResolver const& resolver)
{
resolver.issue (*this);
return *this;
}
template<typename RES>
Query<RES>::operator iterator()
{
UNIMPLEMENTED ("how to get the result iterator");
}
}} // namespace mobject::session
#endif

View file

@ -84,12 +84,12 @@ namespace test {
{
QueryResolver& resolver = buildTestQueryResolver();
Query<int> firstQuery;
Query<int>::iterator ii = resolver.issue (firstQuery);
explore (ii);
resolver.issue (firstQuery);
explore (firstQuery);
Query<string> secondtQuery;
Query<string>::iterator iii = resolver.issue (secondQuery);
explore (iii);
Query<string> secondQuery;
resolver.issue (secondQuery);
explore (secondQuery);
}
template<typename ELM>