January 26, 2017

RBTLIB's Whole-Part Hierarchy

  —A look at implementing a client-side library for Review Board.

In RBTLIB - A Client-Side Library for Review Board I introduced an implementation of a client-side library for Review Board. In that post, I described the next steps for the library including the introduction of the composite pattern to manage the whole-part hierarchy defining a resource.

The implementation includes the composite pattern implemented using named tuples. I chose named tuples because I wanted to avoid an implementation that makes explicit use of meta-classes (named tuples use meta-classes).

I wanted to avoid meta-classes because of my goal for a simple implementation. My notion of simple embodies the notion that the code be straight-forward to read and understand. I find decorators to be a simpler alternative to meta-classes. The "hard part" of using decorators is that the implementation requires decorator chains.

I introduced a JSON attribute to each top-level named tuple. The resulting implementation includes two copies of the resource definition: the JSON attribute containing a copy of the Review Board response and a whole-part hierarchy for each resource component.

The introduction of the JSON attribute is an experiment. I am still not sure what I want from my client application. The applications defined in the scripts still return the JSON structure provided by Review Board. My current rationale for doing this is that I like the notion of using these scripts to support the plumbing and porcelain notion used in git.

For example, an implementation of RB Tools using RBTLIB might rely upon the scripts instead of the RBTLIB API directly. The plumbing and porcelain notion in git works very well and I think the separation of the two might create the opportunity to easily extend RBTLIB or the RB Tools clone very easily.

RBTLIB supports only retrieval of the Root and Review Request resources via HTTP GET. A good test of the design needs to include support for the remaining resources and support for HTTP POST. HTTP POST may take the design in an entirely new direction so there may be compelling reasons to support HTTP POST before introducing the remaining resources.