Form

Dimension

built on type supporting random iterators
min, max, interval / range
discrete / continuous: discrete, bool comparison; continuous, tribool
intended for space, time, measurement (e.g voltage), etc.
support range comparison and searches
absolute, relative or positional
define standard dimensions: they’ll include x, y, z, & t.
Dimensions are fixed at compile time. Limits can be fixed at compile or runtime.

N–dimension iterators (coordinate)

maybe held using map or multimap
order: x then y then z (etc.,), or distance from x,y,z
algorithms: for example, find_if no more than a,b,c from x,y,z
need convertors: e.g. x1,y1,z1 and x2,y2,z2 to relative distance (annoying: technical term is vector!)
x,y,z is cell, not point, to emphasize conceptual differences to geometry

Brane

a tuple of dimensions: will need n–dimensional iterators.
properties, number of dimensions, and dimension limits, are fixed at compile time
max of one, n, or unlimited objects per cell
make no presumption about how content is stored
make it easy to support boost graphs
allow search by dimension ranges
allow external access to content to avoid searches
property list identifies properties relevant to the brane (metaprogramming)
define standard branes. Include x,y space, x,y,t space, etc. A brane with no t is static. Permit multi t branes, but no more than one for the t (give it a special name, maybe "now", akin to "this").

Border

a brane that represents an external device.
properties, number of dimensions, and dimension limits, may be determined at run time.
standard devices include mouse (x,y,t), keyboard (char,t), printer (x,y,intensity), screen (x,y,t,colour), etc.

Coupling

Property Lists

based on boost?
Properties can change according to ability of device plugged in by user at runtime. However, ignoring that detail permits metatemplate optimisation. Should limits be determined at runtime though? How else are different screen sizes managed? But a good number of other dimensions will be limited at compile time. Compile time limits enable serious compile time optimisation (e.g. rather than calculating and converting coordinates at runtime, do as much as possible at compile time). Conclusion: find a way to support both, perhaps via judicious use of const; let the compiler sort it out.
standard properties (all dimensions, plus other to be identified)
values associated with properties? can be ranges?
properties should reflect the abilities of devices represented by borders, amongst other things. For example, the property font will be found on screens and printers, but not on, say, LEDs or violas. Couplings can convert properties across branes, ignore them, or come up with suitable defaults.

2006