[stringtemplate-interest] ST interface: canonical name, and null vs missing vs empty vs nonexistent

[Zenaan Harkness]

On Sat, Oct 17, 2009 at 10:02:25AM -0700, Joseph Grace wrote:
> Another several cents from a lurker in the shadows...
> 
> Penny 1.  "ST" > "Template" >> "StringTemplate" for wide adoption and use.
> 
> Ter's StringTemplate deserves wide adoption.  I believe a short name
> ST is useful in that regard.  If not ST, then Template (but please, no

+1 for Template.

> Penny 2.  Interfacing with Principle of Generous Acceptance
...
> For ST to fulfill its role as ubiquitously as possible, I believe ST's
> interface to the outside world should probably err on the side of
> being generously accepting, not just for Java but for other languages
> as well.  So, building on previous posts, I suggest balancing ST's
> purity of purpose with the need for ST to suit many idiosyncratic
> languages and situations with fewest hangups, hurdles, and surprises.
> In other words, ST should use generous acceptance to ensure ease of
> use without materially compromising its pure separation of model/view.

Ack.

Nice concept/ writeup. Thanks for sharing.


> I believe the following conditionals would help in that regard.
> Perhaps the "." syntax seems desirable, but perhaps not (see penny 3).
> 
>    -  if:  False unless the attribute exists.
> 
>    -  if.null:  False unless the attribute exists, and its value is NULL.
> 
>    -  if.empty:  False unless the attribute exists, and its value is "".
> 
>    -  if.true (for true/false):  False unless the attribute exists,
> and its value is boolean TRUE (for the host language).

I'll Ack something along these lines.

> - if.whitespace: False unless the attribute exists, and its value is "\w*".

We're better off separating "trim" as a function or option, I feel.


> NB: "if.true" (boolean) is defined relative to the host language (not to
> ST), which can vary in meaning w/r/t whether "" is false or not in the host
> language. So the host language (I would say) should be the determining
> factor of the "native" semantics for boolean in ST for ease of use with each
> and every host language. In other words, ST adopts the host language T/F
> semantics for native least astonishment, and ease of use.

That's good for the newcomer, but not so good for the system and library
builders.

Java's awt lib illustrates my point, where 'pixel perfect' layouts
(views) could not be consistently achieved, because the 'platform
specifics' (eg ST host language specifics) were different on different
platforms (languages).

An entire new library (swing) was developed. Not only that, but IBM went
and created eclipse foundation, and they created ANOTHER entire new gui
library (swt). In this case, because awt was inconsistent and
inflexible, and swing was not up to speed, nor free software, at the
time.

So, I have to -1 this one, and strongly suggest that consistency of view
generation, according to a consistent-with-itself and defined-in-a-spec
manner, is essential to some larger projects, which ST should not
ignore.

(YAML has gone through some similar phases, concluding with 'generous
acceptance' principle (not their words) re UTF8/UTF16/Unicode, _and_
clearly defining clear boundaries, syntax and bahaviour, so that
inter-language serialization compatibility is maximized.


> Penny 3. (calling out the "." syntax issue separately)
> It seems to me that the "." syntax could provide a customization hook for
> language/application specific idiosyncracies. Of course, such customizations
> would be frowned upon (for the risk of violating model/view separation of
> concerns) but would leave the door open to unforeseeable idiosyncracies in
> legacy et al. systems. Certain applications could use the dot syntax
> flexibility to add variant conditional(s) to eliminate simple problems for
> input streams for specific domains, and perhaps lead to no-brainer adoption
> where purity would otherwise interfere, without compromising the soundness
> of the ST model (since such customization should be few and far between and
> very specific to quirky use cases). The "." hook could allow some projects
> to adopt ST where they normally could not due to its otherwise
> uncompromising purity.

Good points, and I really get your drive to have ST be widely accepted/
usable etc. I do support this principle unreservedly :)

Regarding per-host-language "customizations" however, unless presented
with an example for which we cannot resolve or otherwise handle
'comfortably' and 'easily' using 'strictly-standard' ST semantics/
syntax, then let's stick to the high ground as long as possible.

cheers
zen

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.