[stringtemplate-interest] null vs missing vs empty vsnonexistent

[Zenaan Harkness]

On Thu, Oct 15, 2009 at 06:24:51PM -0700, Graham Wideman wrote:
> >oh crap. 
> 
> Glad to be of assistance :-).
> 
> >Is it ok if missing and null yield false?
> 
> Probably, but I think you still can't use false to detect missing or null, because that fails to distinguish missing/null from an actual non-missing, non-null MyBooleanVariable=false value.

Ack.

> Eg: What happens if you have an ST template that uses "if" to do something with all the actual boolean false values -- instead it's going to include all the missing and null values as well. And vice versa.
> 
> Hence the "if" feature isn't an escape hatch for not wanting to implement a "missing" option in render.

Ack.

> On the subject of how to treat nulls/missing when it comes to how they should appear in the output, and whether they should get separators.
> 
> First, I think these two issues are intimately tied to gether. Ie: the current null="xxx" and separator="xxx" issues have to follow a uniform policy. Ie: if a template's options are set to omit rendering a null, then it should also omit rendering the delim for that item.

Ack.

I think boolean logic tri-concept, null= ought be complemented with
empty= - it aligns well, is consistent, etc.

> (And it should be legit to say null="" delimiter=",", and get a single comma for null items -- perhaps that's how it works already, not sure).

Ack.

> That said, there's tension regarding how to deal with null/missing (not to mention whether null and missing cases should get separate treatment).
> 
> Should ST make nulls/missing appear or not appear in the output (with delims if so optioned)?
>
> I suggest there's no single right answer to this, hence ST should have the facility to set, as an option, whether nulls/missing appear (as it does now with null="xxx" etc, though maybe some refinement is possible).

Ack.

> The problem is that there's not universal agreement as to what a null or missing item means in a model itself.  

Exactly. So defer to view (ST); = tri-concept booleans.

> For example, iterating a bunch of items that have a "parent" field -- if ST encounters one that whose parent is missing or null -- perhaps that doesn't mean the item has no parent, it means the model just don't know what it is. So in this case we'd like the missing to appear in the output.

Of course. We cannot know the output view needs of a particular system,
or even of a particular view of a particular system...

> On the other hand, iterating a bunch of items that have a firstchild field -- in that case missing could mean that there are no children for this item, in which case we'd like nothing rendered.
> 
> (Somewhat contrived example, poorly thought out model, perhaps. But illustrates lack of agreed-upon meaning for null/missing).

Totally Ack. Thank you for putting the effort into an example at all.
Very useful to assist us in getting our heads around the questions
before us!

> Bottom line:
> 
> I think ST needs to maintain the flexibility of setting an option to include or exclude nulls/missing during render, because neither include or exclude is always the right "no calculation" interpretation of the model.

Ack!

Completely agree.

Only question I think is yet to be properly explored: are there ready
examples where null and missing must/ ought be usefully treated
separately, and if so, should we have a tri-concept boolean logic, or
just stick to two-concept boolean logic, in ST?

zen


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