[stringtemplate-interest] "final" word on null vs missing vs empty

[Zenaan Harkness]

On Wed, Oct 21, 2009 at 11:11:32AM -0700, Terence Parr wrote:
> 
> On Oct 20, 2009, at 8:55 PM, Zenaan Harkness wrote:
> > Any thoughts on making 'if' strict, or providing something like:
> >   if.boolean (a data analysis/ model signal operator), and
> >   if.existence (a data presence operator)
> >   ??
> 
> Well, it's an interesting idea but I lean towards leaving as simple <if 
> (...)> because nobody really complained about this so far.

So concluding, we have:
   -  1) inclusive/ generic/ back-compatible operator 'if'
   -  2) strict data-type test operator 'ifnull'
   -  3) no strict data-type test operator for ifbool?

Or did you just mean not removing the inclusive 'if'?

Of course removing inclusive 'if' would break backwards compatibility
and therefore is a bad idea.

And operators 1 and 2 above are adequate as far as I can tell,
to handle most of the complaints I and others have voiced on
this list.

However, if we consider the concepts, we can group them as 'inclusive'
vs 'strict' conditional concepts.

We can also say that 2 and 3 are data-type analysis tests.
We could say they are data 'shape' operators as you have referred to.

   -  ifnull - standard comp sci special case, often needed;
      suggests 'no shape' or not existing/ present at all;

   -  ifscalar (ifstring? ifvalue?) - a value/string type;
      ifstring suggests data type, where ifscalar suggests shape
      (as in, anything other than list or map);

   -  iflist - self explanatory;

   -  ifmap - self explanatory;

   -  ifempty - the final piece of the 'shapes' puzzle?
      ie for list and map shape testing?
      when combined with first/rest/last/front, ifempty allows
      testing for 'no remaining elements' etc, providing full
      list 'shape processing' ability (vs DP) and plural handling,
      which to my mind aligns closely with view layout of the data;
      this is of course just a bunch of niceness which could be
      pushed back to the model as we know, but strictly is not DP;

The question might be put before us, the question of ST implementing/
providing strictly only 'shape' operators, vs adding data-type
operators.

I think it is only ifnull and 'if' itself that leads to desire to
consider data-type operators. But I don't think data-type operators
are appropriate in general (ifemployee vs ifmanager anyone :)

The limit of consideration for data type (not shape) testing concept
would I think only be for "simple" or "built in" types - but drawing
such a line is another I think very slippery slope (gcc has built in
support for complex numbers for example).
So data-type testing is a strong NACK for me, such to be left to the
[v-]model.

Thoughts?

best
zen

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