[stringtemplate-interest] null vs missing vs empty vs nonexistent
Harry Karadimas
harry.karadimas at hmn.aphp.fr
Tue Oct 20 07:48:26 PDT 2009
Hi,
Sorry for the reply not appearing with the other messages; I
have subscribed to "the stringtemplate-interest Digest" so
I cut and paste the subject for the response, and apparently this does not
always
work so well.
Here are my comments :
> Date: Sun, 18 Oct 2009 12:52:18 +1100
> From: Zenaan Harkness <zen at freedbms.net>
> Subject: Re: [stringtemplate-interest] null vs missing vs
> empty vs
> nonexistent
> To: stringtemplate-interest at antlr.org
> Message-ID: <20091018015218.GA4077 at ip61>
> Content-Type: text/plain; charset=us-ascii
>
> 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.
>
In short, I agree.
>
>
> > 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.
>
> :)
I do indeed ...
>
> 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.
>
>
Let's not overrate these issues; after all st has worked quite
well for me (and for others I guess) in the current form. After
all, having only whitespace in the model may also be treated as
a model issue; if whitespace means empty, the model could be
responsible for trimming strings.
The choice of the operators to propose is not so trivial,
I guess. Self-explanatory words are difficult to find,
because of the ambiguity of words like "empty". Here are
the terms that I use in my java code, let me know what
you think of it, I don't say they are ideal :
1) A general, broad-use operator, to be used in 80-99% of the cases :
if isempty(foo) : foo is undefined, or null, or the empty string,
or only whitespace : in short, it does not contain a meaningful,
useable, displayable value.
2) Specific operators, to be used in more specific cases :
if isundefined(foo) : foo is not defined, no attribute has been set
for foo in st
if isnull(foo) : foo exists but it contains the value null
if isemptystring(foo) : foo exists but it is equal to the
empty string
if iswhitespace(foo) : foo exists but it contains only whitespace
or the empty string
3) Boolean operators
if istrue(foo) : foo contains a boolean with the value true, or
a string that is equal to "true" (case-insensitive)
if isfalse(foo) : foo contains a boolean with the value false, or
a string that is equal to "false" (case-insensitive)
4) No operator at all
if (foo) : what should that mean ? The more practical case would be
for me the value of !isempty(foo). But I admit this might not
have the same meaning for everybody. For me 99% of the times
I want to test if there is something to display, in constructs
like the ones that appear in Terence's paper :
$if(title)$
<h1>$title$</h1>
$endif$
As for an "ismissing" operator, I don't see how we can introduce
a special value that would mean : "foo is defined, and it contains
a value that indicates that a value is missing for it"
Similarly, we could also have a value that indicates "foo is
defined, and it contains a value that indicates that an error has
occurred when its value had to be computed / retrieved"
For the cases of missing value in the model (different from not
defining the attribute in st), and error value in the model, we
should leave the decisions of artifacts of representation to the
model, as there is no accepted standard to represent this in
java/C#, AFAIK.
Best regards,
Harry Karadimas
______________________________________________________________________
Dr Harry Karadimas, Medecin Ingenieur
resp. Recherche et Developpement, Applications medicales
Departement d'Information Hospitalier (DIH)
C.H.U. Albert Chenevier - Henri Mondor
51, av. du Marechal de Lattre de Tassigny 94010 CRETEIL
tel : (00 33 1) 49 81 21 79, [0687353384] fax : (00 33 1) 49 81 27 08
secr.: (00 33 1) 49 81 23 82 m.el.:harry.karadimas at hmn.aphp.fr
More information about the stringtemplate-interest
mailing list