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

[Joseph Grace]

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
"StringTemplate").  Remember, ST aims to be used in languages other
than Java (where lengthy StringTemplate naming may be the norm), but
many non-java languages (especially scripting languages) expect
lightweight naming for ease of use.  Also a short name denotes
convenience, and ST should be convenient.  ST deserves to look and
feel convenient and lightweight, so it can bebe used in lightweight
languages and applications.  IMO, an abbreviated canonical name is
desirable for wide adoption outside Java.  I can see both "Template"
and "ST" working with perhaps "ST" preferable for its brevity and
uniqueness (relative to generic Template).  IMO, shorter canonical
name = better for wide, convenient, and common use.


Penny 2.  Interfacing with Principle of Generous Acceptance

Sticking with the ease of use theme, ST lives to serve its host
language.  Therefore, I believe it should go some distance to provide
a friendly and accepting interface for whatever host languages provide
and expect.  This is the networking Principle of Generous Acceptance
(not its canonical name): "Be strict in what you generate, but
generous in what you accept."  The idea is to accept non-fatal errors
from faulty but discernible data, in order to prevent unnecessary
hangups and congestion.  A bit like the Principle of Least
Astonishment, but specifically for interfaces.

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.

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

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

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.


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.

Cheers,

= Joe =
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091017/3fbd9d7a/attachment.html