[stringtemplate-interest] null vs missing vs empty vs nonexistent

[Zenaan Harkness]

On Thu, Oct 15, 2009 at 04:14:56PM -0700, Terence Parr wrote:
> 
> On Oct 15, 2009, at 2:25 PM, Graham Wideman wrote:
> 
> >
> > At 10/15/2009 01:56 PM, Terence Parr wrote:
> >> was thinking about that but figured it'd confuse. we have <if(!foo) 
> >> foo
> >> is missing<endif> anyway.
> >
> > ...though ! appears to have two problems for detecting the missing  
> > case: it doesn't distinguish between FALSE and null (and missing if  
> > missing is legal here),
> 
> oh crap.  I guess ! would return false if missing or null. Ah. right.  
> I just built this:
> 
>      protected boolean testAttributeTrue(Object a) {
>          if ( a==null ) return false;
>          if ( a==MISSING_ATTR ) return false;
> 	...
>      }
> 
> > and docs I think probably aren't clear on whether the missing case  
> > is legal and treated like null, or should cause error.
> 
> Is it ok if missing and null yield false?

Tis the question.

There are many real-world situations where separate concept treatment,
for these boolean-like concepts, is very useful.

   We system builders/ ST users have to handle the concepts,
   whether or not ST provides in built facilities to assist.


Such situations _can_ (in my experience) always be worked around with
"beefing up" of the view's (ST's) "model" (independent of the "program/
business logic"s model).

   -  This increases complexity of view model generation/ processing.
   -  This simplifies ST templates.


Alternatively, such situations could be handled with distinct concept
treatment by ST.

   -  This would decrease complexity of view model generation/
      processing.
   -  This would cause the two/three concepts to have to be handled in
      various places in ST 'language', thereby increasing complexity of
      ST language.


Q: Have we drawn a line in the sand for ST which says "boolean
operations are not too much logic to encourage creation of 'business
logic' directly in templates"?

If so, then we can add different boolean concepts. We are consistent in
our ST design principles.

It appears to me that this is the case.


At this point (short of other persuasive arguments countering), I am in
favour of separate bool/null/exists concept treatment in ST.

cheers
zen


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