Re: Coercing a list to string (nasty behaviour IMHO)
Re: Coercing a list to string (nasty behaviour IMHO)
- Subject: Re: Coercing a list to string (nasty behaviour IMHO)
- From: Nigel Garvey <email@hidden>
- Date: Mon, 20 Aug 2001 16:55:15 +0100
Axel Luttgens wrote on Sun, 19 Aug 2001 18:36:20 +0200:
>
Now, coming back to the coercion problem, I'm of the opinion it could
>
really be called a bug: even if there were some kind of warning about
>
it, for example in the ASLG (but I couldn't find them), it is abnomal
>
that "{1, Dte's month, 2000} as string" results in an incomplete
>
evaluation instead of a run-time error.
I've been struggling myself to decide whether this should be called a
"bug" or an "incompletely explained phenomenon". What ASLG actually says
is:
"AppleScript supports coercion of a single-item list to any value class
to which the item can be coerced if it is not part of a list.
"AppleScript also supports coercion of an entire list to a string if all
items in the list can be coerced to a string. The resulting string
concatenates all the items, separated by the current value of the
AppleScript property Text Item Delimiters."
This suggests that with a single-item list, AppleScript simply ignores
the list wrapper when interpreting the line. "{Dte's month} as string"
works because it's treated as "Dte's month as string". In the first case,
"Dte's month" is a reference - itself specified as the value of an item
in a list that's to be coerced to string. In the second, it's a reference
expression that's used as part of an AppleScript instruction.
References themselves are not coercible types. In a multi-item list,
their interpretation as value or expression is a scripting matter.
{1, Dte's month, 2000} as string
... means "coerce a list containing the number 1, the reference 'Dte's
month', and the number 2000 to a string." The operation fails at the
second item, not because of an AppleScript fault but because the scripter
hasn't properly described what he/she wants. What's intended is:
{1, Dte's month, 2000}
result as string
... which means "first get a list containing the number 1, the value of
Dte's month, and the number 2000; then coerce this list to a string."
Here, 'Dte's month' is an expression describing the value to go in the
list, not the value itself. All the work-rounds given for the "bug" boil
down to this.
That's my theory, anyway. :-)
What ASLG doesn't seem to say is what's *supposed* to happen when you try
to coerce a list to string when *not* all its items can be so coerced.
This makes it rather difficult to assert that what actually does happen
is a bug:
{1, 2, {fred:"Hello"}, 4} as string
--> "12"
NG