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

[Zenaan Harkness]

On Fri, Oct 16, 2009 at 11:41:43AM +0200, Harry Karadimas wrote:
> Reminds me of the debates about SQL Null
> 
> http://en.wikipedia.org/wiki/Null_(SQL)
> 
> One other question is :
> 
> What must the user know about handling of null values to use st ?
> 
> If st becomes too complex, this will also hinder its adoption, so
> maybe let's not put too many operators/values/cases/options/etc.

Complexity can be ok, as long as there are counterbalancing
factors, such as consistency defaults, consistent treatment/ application
of the concept, completeness - not arbitrarily missing key use cases,
clean syntax, and flexibility for the ST user/ system designer to choose
_where_ in his system to handle different parts of the system's
complexity. Handling strictly view-specific "processing" in the view
specific tool (ST) rather than having to handle that view specific
complexity somewhere else, provides for sanity in the design of the
system, even if that means a slightly more featureful ST.

Hopefully I'm just reiterating the self evident.

Concept handling consistency, is much more important to ease-of-use
(particularly for casual but also regular) ST users, than mere
reduction in number of concepts handled/ provided for.

Eg:
If I have one part of ST (say IF conditional handling) which compresses
all into true or false (btw forcing me to handle 'empty' special casing
with view-model 'hacks'/ view-model compexity increase), yet in say
anonymous list processing the default ST processing is to treat empty
elements as present but empty and I am given special-case option to
'remove' empty elements, then I'm faced with a conceptual inconsistency.
I am forced to remember, depending on which ST syntax/context I'm in,
what the default treatment is in that localised context.
Increase in cognitive load.
Bad.

Conceptual inconsistency is bad complexity.

Incomplete concept handling for the domain being handled (eg view
processing/ ST), is false simplicity.

Conceptually (syntactically, contextually) consistent and complete tools
can and do make the ST user's task easier.

The real world dictates that we handle complexity.

The question is always how well does a particular tool, in this case ST,
facilitate handling that complexity.



> For me mainly three cases are relevant :
> 
> * there is no attribute named "foo"
> * there is an attribute named "foo", and its value is : null
> * there is an attribute named "foo", and its value is a string,
>   which is : "...(whatever, including the empty string)"

And for the next guy, the empty string is as good as a non-existent or
null element.

It is difficult to argue that empty-string vs non-empty-string is any
less valid-view-logic than is existence or non-existence of an
attribute.

Guaranteed, there will be someone's view, somewhere, that requires one,
another that requires the other, and another that requires both, in
order to generate the corresponding systems respective views.

> Maybe a fourth case to test if the value is the empty string
> could be relevant, and this would autmatically lead to a fifth
> case where the trimmed value (removing all spaces, tabs, 
> form feeds, vertical form feeds, ...) is the empty string.

Ah yes, you see the possibility.

:)

Now we're back to handling all cases.

To summarise my points:

   -  Real world dictates we handle complexity.

   -  Incomplete concept handling is false simplicity.

   -  Concept handling inconsistency is bad complexity.

   -  We should aim for conceptually complete, yet consistent, tools
      (according to the domain of the tool eg view handling,
      programming, etc)

cheers
zen

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