Lumiera  0.pre.03
»edit your freedom«
visitor.hpp File Reference

Go to the source code of this file.

Description

A library implementation of the Visitor Pattern tailored specifically to Lumiera's needs within the Steam Layer.

Visitor enables double dispatch calls, based both on the concrete type of some target object and the concrete type of a tool object being applied to this target. The code carrying out this tool application (and thus triggering the double dispatch) need not know any of these concrete types and is thus completely decoupled form implementation details encapsulated within the visiting tool. The visiting tool implementation class provides specific "treat(ConcreteVisitable&)" functions, and this visitor lib will dispatch the call to the* correct "treat"-function based on the concrete target visitable type.

Implementation notes

  • driven by dispatch tables with trampoline functions.
  • uses Typelists and Template metaprogramming to generate Dispatcher tables for the concrete types.
  • individual Visiting Tool implementation classes need to derive from some Applicable<TOOLImpl, Types<Type1,Type2,...> > instantiation and thus define which calls they get dispatched. This is crucial. A concrete type not declared in this way will never be dispatched to this concrete visiting tool implementation class. Of course, the latter is free to implement corresponding "treat(ConcreteVisitable&) functions or fall back on some treat(VisitableInterface&) function.
  • any concrete Visitable subclass wanting to be treated by some concrete tool needs to use the DECLARE_PROCESSABLE_BY(TOOLBASE) macro. By this, it gets an virtual apply(TOOLBASE&) function. Otherwise, it will be treated by the interface of the next base class using this macro.
Remarks
as of 2016, it is not clear if we'll really use this facility; it was meant to play a crucial role in the Builder (which is not implemented yet....). The fundamental idea of relying on a visitor seems still adequate though. For design questions and more detailed implementation notes, see the TiddlyWiki.
See also
visitingtooltest.cpp test cases using our lib implementation
BuilderTool one especially important instantiation
visitor-dispatcher.hpp
typelist.hpp

Definition in file visitor.hpp.

Classes

class  Applicable< TOOLImpl, TYPES, BASE >
 Marker template to declare that some "visiting tool" wants to treat a set of concrete Visitable classes. More...
 
class  Applicable< TOOLImpl, typelist::Node< TAR, TYPES >, BASE >
 
class  Applicable< TOOLImpl, typelist::NullType, BASE >
 
class  Tool< RET, ERR >
 Marker interface / base class for all "visiting tools". More...
 
class  Visitable< TOOL >
 Marker interface or base class for all "Visitables". More...
 

Macros

#define DEFINE_PROCESSABLE_BY(TOOL)
 mark a Visitable subclass as actually treat-able by some "visiting tool" base interface. More...
 

Namespaces

 lib
 Implementation namespace for support and library code.
 

Macro Definition Documentation

◆ DEFINE_PROCESSABLE_BY

#define DEFINE_PROCESSABLE_BY (   TOOL)
Value:
virtual ReturnType apply (TOOL& tool) \
{ return dispatchOp (*this, tool); }
_Fun< SIG >::Ret apply(SIG &f, std::tuple< ARG... > &args)
apply the given function to the argument tuple

mark a Visitable subclass as actually treat-able by some "visiting tool" base interface.

Defines the apply-function, which is the actual access point to invoke the visiting

Definition at line 222 of file visitor.hpp.