Opened at 2026-04-09T18:02:19Z
#1421 new todo
define Instance-Manager interface
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | lesser | Milestone: | 0integration |
| Component: | lumiera | Keywords: | design lib evolution |
| Sub Tickets: | Parent Tickets: | #55, #190, #1197 |
Description
As Lumiera Architect,
I want the concept of an Instance-manager worked out,
to provide a common standard solution for value-like opaque types.
virtualised standard behaviour
When designing components, a fundamental distinction in the nature of those components need to be observed, which is the difference between reference semantics and value semantics. Traditionally, abstractions were tied to reference semantics, which implies that an opaque component with a contract must conceal an entity with a clear-cut identity and a lifecycle. However, new patters emerging from functional and logic programming, have a tendency to blur those distinctions; functional data structures are often leaning towards value semantics. Especially in a performance-critical context, copyable data values are preferable, while complex interwoven structures call for some degree of abstraction, to keep overall complexity at a manageable level.
A possible solution for this dilemma is to conceptualise the basic operations related to a value entity as common tasks of instance management, including the operations to copy, move, assign, swap and destroy individual elements. This patter is e.g. used within the typical implementation of std::function, where an — otherwise opaque — functor object becomes attached to a generic handle that represents an anonymous function; like any handle, it is expected to be lightweight, disposable and copyable, while the functionality abstracted away can possibly involve extended data structures and incur further liabilities.
Packaging this set of common instance management operations as a finite structure allows to separate these concerns from the actual domain logic — which helps to reduce complexity significantly, as these common base operations have a tendency to become intermingled with the non-trivial aspects of data structure management. Furthermore, access to such an Instance Manager can itself be virtualised, leading to a pattern known as »Virtual Copy Support«. In the context of C++ it should be noted that the implementation of those common instance operations is typically inlined, so that a virtualised implementation of an Instance Manager is typically tied to the concrete type of the »Instance« being managed. This can be potentially dangerous in a situation where a lot of instance variations is being generated, which, for example, is the case when abstracting over a »function signature«, or an »iterator«. It seems prudent thus to represent all those operations together as a single, unified function (using a selector ENUM to specify the actual operation to carry out). Abstracted Instance Management can then be represented by a single function pointer, or, in case of a virtual function based interface, by the addition of a single virtual function to the VTable.
