On Sun, Jul 6, 2014 at 11:13 PM, Gavin Lambert
On 1/07/2014 08:14, Michael Powell wrote:
So far so good, makes sense parsing names and so forth. However, how do you handle element content? Which could either be a string, or zero or more other elements (basically of the same rule as the enclosing element rule).
It would seem you need a terminus, the empty element tag. In such a way that populates the parent (initial) element, and its children (of the same element kind).
Usually this sort of thing is resolved by using nodes -- a node is the basic base type of everything, and the entire tree can be treated as a homogenous tree of nodes. But specific derived types of nodes vary in behaviour, eg. an element node represents a tag, an attribute node modifies its parent element, a text node can only contain basic text (no sub-nodes), a whitespace node can only contain whitespace (and can be discarded or reinserted unless it's a significant-whitespace node), etc.
You could either use actual inheritance or you could make "node" a variant type over the various "subtypes". Which one makes more sense may depend on how much implementation they end up wanting to have in common.
It's an interesting question, thank you for the insight. I get what you mean, and yes, it is all about trade offs, between utility of the domain model and developing a grammar that will help, and not hinder, the domain model. The interesting questions are to do with how and when to allow children (i.e. likely not in a comment node). It could be that generally everything can be modeled as a tree, i.e. xobject children of xobject parent, with appropriate specializations and/or treatment of references, pointers, iterators, etc. Then the trade off is trusting that the end user is responsible with his/her usage of domain model.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users