jastrachan | 11 Mar 14:39 2005

Re: NULL and Strings

On 11 Mar 2005, at 11:16, John Rose wrote:

> These are very good questions.
> On Mar 10, 2005, at 18:02, jastrachan@... wrote:
>> On 11 Mar 2005, at 00:37, Mark Igra wrote:
>>> It's rare that people actually want to concatenate the string "null" 
>>> with a
>>> string, so I don't think changing this rule would change the 
>>> semantics of
>>> code people really expected to write.
> Yes.  The string "null" is almost never what you want, except maybe as 
> a gentle hint that you've made a programming error.
> I wouldn't cry if Java programmers had to say ${String.valueOf(x)} or 
> ${x || "null"} if they really wanted the "null".

Me neither actually :)

Maybe inside GStrings, we have license to do things differently?

     def bar = null
     String foo = "hello $bar"
     assert foo == "hello "

Though for normal string concatenation; should we change things? This 
could lead to surprises

e.g. the semantics of

def x = null + "text"
def y = "text" + null

should they follow Java's lead to avoid surprise. Or would it be more 
surprising to allow GStrings to use "" for null values, but keep Java's 
rules for adding nulls to strings?

>> BTW we could support an extension to the GString syntax borrowed from 
>> Velocity...
>> def foo = null
>> println "Hello $!foo"
>> which would only print the value of foo if its not-null
> Formatted strings often have a need to specify some variation in the 
> ways substrings are inserted.
> This is true with SQL scripts, shell scripts, XML concrete syntax, and 
> simple string construction.
> (Briefly:  Do you add quotes and escapes according to the target 
> language, or just insert willy-nilly?)
> Note also that SQL takes non-string data values under ${...}, not just 
> substrings, and so could an XML renderer take elements, etc.
> I think there's an analogy here with the ?. and *. operators, where 
> null and lists get special treatment.
> (Note that shells also have special treatment for lists, though 
> imperfectly where embedded blanks are involved.)
> There is a syntax "$*x" partially implemented in the new parser, to 
> cover at least some of these problems.
> We haven't had time yet to fill out the rules, but it's clear there's 
> a degree of freedom here which needs control.

Yes. The default toString() on a GString can have the out of the box 
handling of nulls; a library (such as the SQL tool) could interpret 
null differently (or perform some kinda coercion, such as if it is an 
XML streaming tool etc).