[stringtemplate-interest] On Pragmatism Violating Purity

[Joseph Grace]

*Graham, thank you for a great insights and suggestions.

Graham Wideman* wrote on *Mon Oct 19 16:11:21 PDT 2009:***



*

> 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.

Mmm, perhaps, but I think operators are pretty core.  I think any
solution would involve operators since they're core.  Perhaps they're
just a good starting point, jumping off point for discussion?

BTW, I just finished reading many posts on this mailing list from
2009, and there are definitely use cases for making ST more adaptable
to model input, so I think ST could definitely benefit from some TLC
in this area.

> 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".

I think you make a good case that "if" is limited in solving all the
problems.  However, "if" is a key for ST, so getting it to work nicely
still seems compelling, even if insufficient.  You make a case (and
from past posts I've read), there are plenty of niggly little data
importing issues that crop of to cause impedance mismatches between
model and view/ST.  As you suggest, even a multi-headed "if" is
insufficient to solve them all.

Past posts and your well-written expose on "if" et al. convince me
that the language and user based customizations _will_ get used to
make ST adapt to various situations it smugly avoids now.  Once ST is
willing to solve the niggly import issues, I believe ST will get more
use.

Which is a good segue to your final suggestions...

> avoid using the keyword "native", and instead use the keyword for the language:  java.somefunction or csharp.somefunction etc.

+1, and

> com.yourdomain.somefunction

+1

I was cracking up when I read your suggestions, because they're spot
on, I didn't see them coming, yet I was thinking in the same
direction.  My next suggestion was:

model.*

So "native.*" is out.  It was bugging me.  I was thinking "lang.*" but
hadn't thought to actually specify the language.  Your solution is
great.  I also was thinking about "user.*";  again, your solution is
better.

Let me explain my "model.*" suggestion even if it turns out inferior
to your suggestions (not to mention a little tongue in cheek:-).  What
I realized is that unsolved interfacing problems in the mailing list
degenerate into exhortations of "Do it in the model!".  In other
words, whenever a model doesn't provide exactly what ST needs (and ST
takes a pretty narrow view of data), the model has to get "fixed" when
it wasn't broken.

That's a problem for two reasons.

1.  If the model isn't broken, why is it being fixed?  In other words,
why can't ST handle normal stuff like everything else on the market?
(Answer:  because ST is pure, and doesn't do "model" like the rest of
the template engines.)  That's what makes ST cool... and what makes it
suicidal.

ST needs to be friendly to models, and by friendly I mean:  Be
generous in what you accept!

If ST can not adapt to "normal" models, then it's useless in many
situations, and dangerous to standardize for unknown/future projects.
For example, what if the model can not be changed?  That happens,
right?  That's what ST strives for:  total separation of view and
model.  What if it's literally the case that they're already
separated, and the view simply has to make do?  Then saying "Do it in
the model!" is an admission of ST failure.  Unacceptable.

I read a thread where one guy was very polite, understood the value of
ST's separation of concerns, but struggling to make it work.  He kept
requesting relief for niggling data massage problems (e.g.,
calculations, filtering, little stuff).  His final answer was that he
doesn't have access to the model, so he can't change it.  The official
response was essentially: Do it in the model, or bust!  I don't think
he ever posted again.  I bet he dropped ST like a hot potato (and for
good reason).

That's garbage (not him, ST's smug attitude, "Do it in the model, or bust!").

ST has several advantages.  One it's more often than not an endpoint
for processing.  So it only has to serve one master --- the model on
input.  So it should at least make itself as easy to use by the model
as possible (a la the "Robustness Principle", "Be generous in what you
accept!", ease of use, adaptability, and all that).

Second, ST is usually the new kid on the block, so it's installed base
in each new project is small, simple, and blank slate.  It's a perfect
place to add complexity when the rest of an application is overloaded.
 Yeah, I said it:  add complexity.  Sometimes model stuff is easier
done elsewhere.  That's what people keep asking for, projects keep
asking for, and desperate measures keep asking for.  So, ST should
help out (again, be easy to work with).  Again, just saying "Do it in
the model!" is purist gobbledygook, and from an engineering standpoint
can even be wrong.  Sometimes its better to offload straightforward
stuff to endpoints (e.g., ST).

So, my epiphany is that all those posts exhorting poor infidels to "Do
it in the model!" would suddenly come true.  With

>  model.*

With "model.*" user custom hooks, anyone could do anything in the
model, including massage input for easy processing in ST.  The
perennial exhortation "Do it in the model." could remain true, and yet
ST would be easy to use and adaptable by providing an outlet for model
massaging, "model.*".

So even mundane non-view stuff could be done in model.* (trimming,
calculating, filtering, etc.) with native language support, but apart
from ST itself.  Sure it's violation of purity, but not of ST purity.
Model massage is segregated to "model.*" and that's fine.  Suddenly
the world doesn't have to adapt to ST;  ST can adapt to the world.

Much better for all.

Plus, model.* customizations take some of the pressure off ST to
handle any but the most straightforward model stuff (such as themost
basic "if.*" cases).  Model massage can take care of the rest.  ST
gets to maintain its sanity, while being much more adaptable to real
world situations.

Prospective users don't have to worry about getting rabbit-holed (etc.
etc.) by ST purity, or "fixing" a model that already works (just
because StringTemplate demands it).  Impure code goes in "model.*" (in
the model where it's supposed to be :-).

My reading of the list suggests such an escape valve is sorely needed
for massaging data on the way into ST but criticized every time
someone gets too pushy.  IMO, ST should shoulder some of the massaging
work when necessary.  I was tempted to call massaging "middleware.*",
but "model.*" says it all, and keeps the advice "Do it in the model."
as current as it ever was.

-=-

However, Graham's suggestions about language specific or even domain
specific names are well taken.  After my reading of the list, I found
cases of shared language specific code ('if you're using java, just
email me for the code'), and also some demand for custom hooks and
massaging to get data into ST without modifying preexisting models.
So, taking the long-view with the domain names may be appropriate.
I'm open to either or both!  I'll think on it, and look forward to
other insights.

Thanks for the suggestions,

= Joe =


*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091019/af02ffb7/attachment-0001.html