"I don’t spot a ‘rot’ attribute there. "
No, the train track diagram describes only the game-box.xml file. ‘rot’ appears to be an attribute on the [counter/] element in the scenario files and seems to have values in 60 degree increments. Sorry, my mistake, I was conflating the two file formats.
Brent: “…I am aware of is tinkerers poking around …”
Lighten up will ya? I conceded that history determines how we got here. I’m not being a purist, I’m just trying to make a suggestion (that I concede is not completely informed)
What I was talking about was the early part of the property string which appears to reproduce the hierarchy of the pane/tab/list structure in which the piece is to be placed.
I’m probably be wrong, but it appeared to me that
a.) this was redundant when destreaming from XML because the enclosing structure tells you where to put the piece.
b.) it appeared to be an artifact of the effect referred to by Joel where instantiation of the prototype is required
I’m probably jumping the gun, but it also seems to me that b.) is a side effect of the Decorator pattern - if you want to instantiate a decorator you also have to know how to instantiate the decorated object, so you end up embedding construction details of the decorated object in the decorator stream - ie. leading to the complex-relationships-in-the-buildFile that Joel referred to earlier in this thread. ie. parts of the property string refer to enclosing XML elements and vice versa.
My question was then:- if this structure is a side effect of the Decorator pattern (which I suspect it is) wouldn’t something more decoupled be appropriate? Something like:
use an XML specification for the PieceSlot instantiation and use only the enclosing XML to specify where it needs to go
use only a pointer to the separate (?) prototype chain parent for navigating traits
For the second, Chain of Responsibility is kinda close (although the dispatch would have to terminate at the first point in the chain where a handler was found). CoR doesn’t require any inheritance relationship between the types and their methods (aka traits) so it seems to me to obviate the need for instantiation.
Going on, the problem of old prototypes in files might then go away as (so far as I understand it) the old version of the prototype is also defined in the same file.
It’s just a suggestion. I noticed you guys discussing this issue and I encountered the problem of complex relationships between property strings and other parts of the buildFile when trying to manually rewrite the buildFile.