2008-08-10

Closing Block Tags

I don't understand why define and face have their own special enddef and endface, respectively. I'm missing what the benefit is to not just using the regular end. Any hints?

2008-08-01

World to Parser to Objects to World

Several design/implementation issues/choices have been swaying me back and forth. I think the following is a fairly sane plan:
  1. World is instantiated, stream to BZW passed
  2. World instantiates Parser, registers anything necessary*
  3. World passes BZW stream, possibly reference to self, to Parser
  4. Parser runs BZW source through Spirit parser.
  5. Spirit parser instantiates World Objects (populating the World reference)
  6. Spirit sends World Objects individual line data, such as size or position
  7. Parsing complete, World populated
  8. Any remaining group/magic left is handled
  9. Populated World object returned
(*: This depends on whether or not the Parser will know about objects beforehand (hard coded), or if the World should inform the Parser of objects through an interface.)

Letting the World Objects "parse" themselves (similar to the current implementation in BZFS' BZW reader) allows for some code reuse on the World Object end (copy much from BZFS' Custom*.read implementation), less complexifcated Parser object (and improved coherence and decoupling), as well as less Parser set-up, as the Parser should need to know less information. Things such as duplicate entries would be managed by the World Object's parsing, which could take advantage of STL's string/stream extraction operators.