advice.hpp File Reference

Go to the source code of this file.

Description

Expecting Advice and giving Advice: a cross-cutting collaboration of loosely coupled participants.

This header exposes the basics of the advice system and the public access points. The advice system is a system wide singleton service, but clients never talk directly to this singleton; rather they use advice::Provision and advice::Request as access point.

Advice collaboration pattern

rationale

Advice collaboration is a special pattern of interaction extracted from multiple use cases within Lumiera. Advice can be used as a Whiteboard System for exchange of dynamic facts, without imposing any direct relationship onto the participants. Initially, this abstraction was to some degree inspired by aspect oriented programming, especially the idea of cross-cutting the primary dependency hierarchy. Another source of inspiration where the various incarnations of properties with dynamic binding. For defining the actual binding, we rely on predicate notation and matching (planned: unification) as known from rule based systems.

Definition: Advice is an optional, mediated collaboration between entities taking on the roles of Advisor and Advised, thereby passing a custom piece of advice data, managed by the advice support system. The possibility of advice is created by both of the collaborators entering the system, in any order, where the advised entity exposes a point of advice, while the advising entity provides an actual advice value.

Collaborators

• the advised entity
• the advisor
• point of advice
• advice system
• the binding
• the advice

Usually, the advised entity opens the collaboration by requesting an advice. The advice itself is a piece of data of a custom type, which needs to be copyable. Obviously, both the advised and the advisor need to share knowledge about the meaning of this advice data. The actual advice collaboration happens at a point-of-advice, which needs to be derived first. To this end, the advised puts up an request by providing his binding, which is a pattern for matching. An entity about to give advice opens possible advice channels by putting up an advisor binding, which similarly is a pattern. The advice system as mediator resolves both sides, by matching (which in the most general case could be an unification). This matching process creates an advice point solution – the advisor is now able to fed the piece of advice into the advice channel, causing it to be placed into the point of advice. After passing a certain (implementation defined) barrier point, the advice leaves the influence of the advisor and gets exposed to the advised entities. Especially this involves copying the advice data into a location managed by the advice system. In the standard case, the advised entity accesses the advice synchronously and non-blocking. Typically, the advice data type is default constructible and thus there is always a basic form of advice available, thereby completely decoupling the advised entity from the timings related to this collaboration.

Interfaces and implementation

Client code is assumed to interface solely through the advice::Request and advice::Provision classes, which both can be instantiated and copied freely, may be used as member or mixed in as baseclass. The AdviceSystem on the other hand is an implementation facility (actually a singleton) and lives in the advice.cpp translation unit. The interface entities mix-in the protected implementation from AdviceLink, which is implemented in the same scope as the AdviceSystem and thus is allowed to talk to it directly. The AdviceSystem in turn uses advice::Index to keep track of the collaboration partners, which, for this purpose, are handled as type-erased PointOfAdvice elements. The latter class contains 4 API functions used by the index to manage solutions.

Note

as of 6/2010 this is an experimental setup and implemented just enough to work out the interfaces and gain practical usage experiences. Ichthyo expects this collaboration service to gain relevance over time for several use cases within steam-layer.

Todo:

allow variables in binding patterns

use the lumiera MPool instead of heap allocations

consider to provide variations of the basic behaviour by policy classes

the implementation is generic/defensive, and could be improved and optimised

See also

AdviceBasics_test usage example

advice.cpp implementation

advice::Index index datastructure

binding.hpp

Definition in file advice.hpp.

#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/null-value.hpp"
#include "lib/symbol.hpp"
#include "lib/util.hpp"
#include "common/advice/binding.hpp"

Classes
class	ActiveProvision< AD >
	Piece of Advice as incorporated into the AdviceSystem. More...
class	AdviceLink
	Advice Collaboration partner, internally connected to the AdviceSystem. More...
class	PointOfAdvice
	Basic (abstracted) view of an advice collaboration partner, as used internally by the AdviceSystem to manage the participants. More...
class	Provision< AD >
	Access point for the advising entity (server). More...
class	Request< AD >
	Access point for the advised entity (client). More...

Namespaces
	lumiera
	Lumiera public interface.