Ichthyostega
6de24bc7f0
to carry out that rather obvious step, I was bound to consider all the implications of choosing a given layout and handling pattern for our external structure representation. Finally, I settled upon the following decisions - the value space represented within the DataCap is flat, not further structured - the distinction between "attribute" and "nested object" is merely conceptual and will be enforced solely by the diff detection / representation protocol - basically, a nested subtree may appear as an attribute; the difference between attributes and children lies solely in the way of access and referral: by-name vs. positional - it is pointless to save space for the representation of the discriminator ID - but we can omit any further explicit type tag, because - we do *not* support programming by switch-on-type, and thus - we do *not* support full introspection, only a passive type-safety check - this is *not* a limitation, since we acknowledge that GenNode is a *Monad* - and the partial function needed within any flatMap implementation maps naturally onto our Variant-Visitor; thus - the DataCap can basically just *be* a Variant - and GenNode has just to supply the neccessary shaffolding to turn that into a full fledged Monad implementation, including direct construction by wrapping a value and flatMap with tree walk |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| empty.html | ||
| renderengine.html | ||
| uml | ||
| workflow.mm | ||