| « What Is the Difference Between a Mutator and a Snapshot in Memento? Is It Significant? | XSS » |
Stencil by Convention
May 7th, 2007
When toying with Stencil at the outset, I dipped into the JavaBeans API. It seemed like the easiest way to get started on a dirt simple path language to extract string values from Java objects. I’d replace it when a better idea came to me.
Still waiting.
I created a an interface. Given an object and a property name, an implementation would extract the property form the object. There were two distinct implementations of name and value pairing that were apparent at the outset. JavaBeans, which are ObjectS whose properties are obtained though the JavaBeans API, and MapS. Certainly, there would be more.
There weren’t.
The API programmer was burdened with choices. Not only did you have to provide an object model for a Stencil, you needed provide a was to interpret that object model? Flexible? Sure. As flexible as 0 and 1.
This calls for a convention.
An object returned from a property is either an Object, Map, array, Collection, Iterator, or a ListIterator.
ObjectS, through JavaBeans, and MapS are interpreted as name value pairs. They give named values for a dirt simple path language.
Colletion and Iterator are used by the each keyword. A Java array or ListIterator expose an index property to the each keyword.
The Liberty of Convention
Amusing to think of how it hit struck me though. That word; convention. It freed me from sifting though design patterns, thinking up ever more convoluted means of delgation, dispatch, configuration, and construction.
One mental block was an avoidance of the instanceof keyword, which always feels like your cheating. However, this time around, I realized that I was already employing reflection, and that binding begs reflection or similar.
Once I’d decided that instanceof was the way to go, then it became a matter of deciding, instanceof what?
