[stringtemplate-interest] On Pragmatism Violating Purity

[Graham Wideman]

I am currently not sold on the importance of native.if per se, and feel that it's trying to address a genuine problem, but at the wrong place.

Thinking on native.if
-------------------------
First, the motivation behind native.if seems to be that direct access to whatever "if" means in the native language would allow templates to understand the model in the same way the app intends.

But this presupposes that (native) "if" is the (only) tool which the calling app uses to understand out-of-band values in its model. That I think is unlikely.

Instead, the designer may well have depended on evaluating such variables with explicit tests of missing, null or comparison to "", and so on, only some of the time using "if" if it happens to do the desired thing.  

Indeed, a fair proportion of the time an app designer has to go to some effort to take care of nulls arising from database queries, or database prohibiting empty string and converting to null, or application use of strictly typed vs variant type variables, and so on, so that there's a high level of awareness to *not* align the meaning of out-of-band values with language idiosyncracies in this area, and instead to be careful to deal with them explicitly.

So, maybe there's an argument to provide, within ST, access to particular native language features, but I am skeptical about it's importance in the area of "if".  If it's reasonable for ST to be able to interrogate values at all (and thus have an "if" capability), then it's reasonable for ST to test all variants of absence/missing/null/empty that ST can "see".  If ST can "see" into native data structures by virtue of its reflection-following capability, then it can also encounter absence/missing/null/empty in various ways and should allow the ST programmer a way to tell what to do about each case.

There is an alternative strategy that better preserves model/view separation, and that's for the model (ie: callign app) to tell what to do about null/missing/empty on the model side, and for ST to be able to read that.  One could imagine ST's Attribute containing not just name and value, but also the default values for each case: defaultForEmpty, defaultForNull, defaultForMissing (and of course these could be made native-language specific, with no impact on what one writes in a template).

But this line of thinking is subverted by ST's capability to use reflection to access subsidiary properties of an aggregate object that the caller explicitly supplied as an Attribute. Then Attribute would need a way for the caller to supply defaultForNull etc for each subsidiary property that ST could reference... and at that point the design of ST Attribute would devolve toward requiring each data item as a separate Attribute (so it could have its own defaultXxx's) rather than as part of an aggregate.

Summary: ST bent strict model/view separation by providing the convenience of ST-driven selection of data via aggregates that a template can access. That precluded setting defaults for various "out of band" values for each data item. That necessitated ability on the template side to test for some out-of-band values (if, null="xxx"), but this feature set is incomplete. (A second partial workaround is supplying your own render function.)

My current conclusion is that the current state of compromise is best complemented by rounding out ST's handing of the out-of-band values it can encounter, by completing the set of ifxxx functions, and the set of defaults one can specify for rendering (and make them parallel).

native.somefunction
-------------------------
Second, if there is a move toward a native.somefunction idea, then how about avoid using the keyword "native", and instead use the keyword for the language:  java.somefunction or csharp.somefunction etc.  Then it would be immediately clear what's going on, and the ST interpreter compiler could readily reject attempts by a template that expects C somefunction behavior to be used where it's getting java somefunction behavior. (And one would be prevented from accidentally reusing a template written for one native language in an incompatible scenario.)

Finally, would this really be heading in the direction of native-language specific functions, or is it really about adding user-defined functions to ST: ie: user.somefunction.  Let me be the first to suggest....

com.yourdomain.somefunction

:-).

-- Graham