[stringtemplate-interest] On Pragmatism Violating Purity For The Win

[Jonathan Buhacoff]

I think the dive into if.*, render.*, etc can be avoided because:

1. The model author can easily create that functionality plus handle  
various forms of "empty" using renderers or wrapper classes as  
described in Terrence's papers, and in fact I use "render-time"  
computations routinely in my projects

2. The only thing that, IMHO, could really use a new operator is null  
vs non-null which right now can only be tested for non-boolean values.  
I think the "if" operator's behavior can stay exactly as it is, we  
just need an additional "ifnull" to test for null booleans (or that  
any other value is null/missing).

The other issue that was related to this discussion was how to treat  
nulls in lists. In my experience, the most convenient thing to do with  
nulls in lists is to drop them, but of course it's not always the  
case. I think it would be conceptually simple to drop nulls by  
default, and include them with an option. It would be analogous to  
leaving the current behavior of "if" and adding an option to check for  
null explicitly via "ifnull".

<if(attr)>     analogous to    <multi-valued; separator={,}>  because  
they both ignore nulls

<ifnull(attr)>    analogous to   <multi-valued; separator={,};  
null={}>   would include nulls AND allow a template author to decide  
how they get rendered, by supplying an aribitrary template.  So they  
can be rendered as an empty string with {}, or as the word NULL  with  
{NULL},  etc.   Terrence gave an example of this in the summer, with  
null="6".


--
Jonathan Buhacoff
jonathan at buhacoff.net
--



On Oct 18, 2009, at 6:22 PM, Zenaan Harkness wrote:

> On Sun, Oct 18, 2009 at 05:59:07PM -0700, Joseph Grace wrote:
>> *Zenaan Harkness* wrote on *Sun Oct 18 15:39:12 PDT 2009:***
>> *
>>
>>> I guess my concern is that if such a feature were in ST, that it  
>>> not be
>>> so simple to type that people would use it as the default true/false
>>> test.
>>
>> I don't see "if.true" becoming the default test.  FYI, I see "if"
>> (i.e., the common already in-use operator) as the default.  That's  
>> the
>> legacy code, so that's the likely default, not some newfangled
>> operator that is optional.
>>
>> How about a name change from "if.true" to "native.if"?
>
> native.* seems clear enough.
>
> That could be suitable. I'd still like to see an actual use-case-
> with-code that requires this though.
>
> ...
>> Purity prohibits even one operator of native compatibility.  That
>
> If we added native.if, are there other operators you see
> being useful in the native.* library?
>
>
>>> Need a concrete example of a problem it solves. Hasn't been an  
>>> issue on
>>> the lists before know, and this discussion so far we've had the  
>>> luxury
>>> of living in hypothetical land.
>>
>> I'm confused.  This whole topic started with the discussion of
>> splitting "if" into "if" variants.  That's a real world issue from
>> this list.
>
> Modifying ST into 'platform specific' variants is a significant
> change if it were undertaken.
>
> An actual example would be useful to the discussion.
>
> I'm thinking that an actual example, which clearly identifies
> the problem from a specific language (eg python, C#, whatever)
> might be easy to counter with existing simple ST techniques.
>
> If native.if were the only elegant solution, then that would be
> useful information to the discussion ...
>
>
>>> Again, there are more areas in st, where host-env specific stuff  
>>> could
>>> be applied. No point adding just one without also addressing the  
>>> others.
>>
>> Umm, I'm assuming this is the proverbial can of worms you are afraid
>> of?  Is that where all this confusion is coming from?  FYI, I am just
>> talking about this one feature (or some well-constrained variant),  
>> and
>> I think this feature has merit on its own.  (Let the other issues
>> stand on their own merits.)
>
> It may have merit enough to stand on its own.
>
> A native.* library would be good to think/ plan for in advance
> though, rather than one feature at a time, don't you think?
>
> Good discussion
> zen
>
> -- 
> Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
> Please respect the confidentiality of this email as sensibly  
> warranted.
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest