My apologies for waiting so long before posting a reply.. I just did a couple of 22-hour days back to back (as a stagehand, not as a coder).

Firstly, your approach is bottom up. Most successful Object Oriented Design starts with defining the problem, working out the entities and relationships, deciding on which classes to use, then designing the code.

I tend to side with Knuth with regard to the top-down/bottom-up debate: both ideas are useful, but the best software design tends to happen from the middle out. Check out Literate Programming (D.E. Knuth; CSLI Publications; ISBN: 0937073814) for a wonderful treatment of the subject.

Both the top-down and bottom-up methods give programmers ways to sweep bad decisions under the rug. Top-down design shares the same basic weakness as testing, in that you can only design (or test) for the problems you know about. Checking your top-down design won't tell you about missing assumptions, or assumptions that contradict each other in subtle ways. Bottom-up design, OTOH, tends to fall prey to circular logic. Every piece of code ends up needing to be the client for some chunk of information, but nobody wants to take responsibility for it.

You need bottom-up information to make sure your top-down design is both complete and self-consistent, and you need top-down design to keep your bottom-up pieces from wrapping themselves up into a snakepit of mutual dependencies.

In your case, this is forgiveable if it is purely a learning exercise to teach yourself about OO.

Minor misunderstanding: I'm not doing this to learn about OOPerl.. I've been doing that for years. I'm doing it to learn about compilers and parsers, specifically in terms of applying my own OO preferences to the job of building a compiler. I have read Parse::RecDescent, and I think it's a wonderful piece of code. I'm just exploring my own ideas about how to partition responsibilities.

Finally, consider gaining an understanding of design patterns.

*grin*

I'm already a Patterns junkie. My copy of GoF is well-worn, as are Fowler's Analysis Patterns and Pattern Languages of Program Design vols 1-4. I also have architect Christopher Alexander's 7-book series on urban design, of which A Pattern Language is volume 3.

The 'error state' that I introduced in pass 10 is actually an application of the Null Object Pattern, for instance.