BrainBrain View Note

For this session we decided to try pick up on a trail of development I started on my own. Many zealots are already likely to be angry: you can't just pick up on something that already exists, it is meant for new code. My response to this is the same as always, regardless whether it is a library, a method, a tool, or otherwise: if it can't work with an existing code base, then basically it is worthless for most people. New projects with new a codebase are the exception, and thus no valid method may assume this as a starting point.

The feature we would be implementing is a data listing: loading data from a database and displaying it on the web. This needs to be done within the existing schema framework whereby a schema completely defines the data in the system, and a code generator in the middle produces a standard API for the programmer. Adding the listing feature is an exercise in adding something at every step of the process.

Specifically our target system is a web application, or HTML pages, with PHP as the primary programming language. The particular data were processing rules for a failure classification system, though it isn't so relevant here.

Our starting point is one likely familiar to TDD programmers, working from our ideal use scenario inwards. On one side we had how our schema definition of the listing should work, and on the other side we had how the final PHP code for the listing should look. I had basically done this before the session started, but that didn't stop us from discussing it.

As the syntax was derivative of existing syntax we had previously discussed, there weren't too many remaining conversation points. However, there was one particularly nasty new syntax that consumed us for quite some time. Such discussions are normally helpful, and can easily be seen to improve code quality. But I don't need pair programming for these. Nor am I convinced that pair programming would naturally tend to such discussions.

Syntax aside, we're left with needing to extend the parser, the processor, the code generator, and the support classes. Again here, I had already done the support classes for the generator, and had a working sample of code, which the generator would emit. So we needed only to focus on the parser, the processor, and the emitter.

The Parser

The parser builds the abstract syntax tree (AST) and it seemed like the logical place to start. It is a recursive decent parser which tokenizes as needed. In this case my partner was reasonably well versed in parsing, such that this was not just total nonsense, but I fear this to be one of the stumbling blocks in pair programming. What if your partner simply doesn't have the background knowledge required to even approach the problem?

My partner was able to ask why isn't a standard grammar generator being used for this. I agreed that it is a vital question. But what if my partner hadn't done any parsing before? Worse, what if I I had no idea about parser generators? Who would have asked that absolutely critical question?

Beyond that the work was rather routine: add a few lexing functions and add some reduce rules. The pairing communication here was primarily one-way as I explained to my partner how everything was working and pointed out conventions being used. My partner gained some more knowledge of the system, but the code was in no substantial way improved.

Here is another interesting roadblock though. My partner had some good observations about the structuring of the parser itself, and I agreed that something should be done. However, this had little to nothing to do with what we needed now. Refactoring that code would take a long time, and would bring us no closer to solving the problem we just started. We decided to ignore it and continue.

The Processor

For reasons relating to an evolving syntax, and for speed of implementation, the parser only produces an untyped AST, little semantic processing has occurred. The processor takes the AST and produces a fully-typed and linked version of the original grammar.

This code is confusing. Need it be? Well, because of the separation of parser and processor, yes, but if the whole thing was rewritten then, well, maybe not. But nothing stronger than maybe. My partner had some small suggestions, but nothing that would have greatly improved readability.

Though at this point we needed an interlude to a particular PHP syntax:

$entity = $types[$name];

versus

$entity =& $types[$name];

The difference is technically simple, but exactly how this works in PHP is a mind boggling journey in dementia. But it's not my dementia, PHP created it, so why do I have to explain it to my partner? Can I not just point him to the documentation and let him figure it out? Should he just be willing to trust me that I have the right syntax?

If the answer is no, then I see another pitfall to pair programming. Should the pair be of diverse experience level, or radically distinct backgrounds, the session will likely become one of teacher and student, rather than co-programmers. I have no problem with mentoring, but realistically this type of situation greatly reduces the contribution of the student and it consumes a great deal of time.

In any case we punched through the processor and verified it worked with some PHP var_dump commands. On to the code generator, or emitter as we call it.

var_dump is one of those little, yet very nice, surprises that PHP has. It is basically like printf debugging with steroids.

The Emitter

Once there is an in memory representation of the listing, which is part of the overall schema definition, we need to emit the PHP code that implements it. As I had already coded the final form of this it was basically an exercise in templating.

Again here was a lot of one-way teaching rather than co-programming. I'm not sure how this can be avoided when working on a existing code base. This time however was mainly many more small things, though mostly related to PHP syntax rather than the new feature.