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 converters: 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
- conversion between branes
- make no presumption about how content is converted
- supports view on each brane
- converts coordinates and properties
- property list identifies properties converted (metaprogramming)
- mechanism to identify and prod?
- define standard conversions
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.
