Hi,
Note that it is a good idea to do it but, it won’t cause bugs if your app is rerun.
gl,
kel
Wow! Went home Friday night and came in this morning to quite a read.
Please can someone list the example that won’t easily get you into hot water, is backwards compatible, we would be encouraged to use, doesn’t rely on SD or AS Editor to reset/remember what TIDs you’ve set etc and isn’t necessarily a one-liner.
Thanks guys 
That’s actually not the reason to set the text item delimiters to the old values, otherwise you could set text item delimiters just to “” instead of the previous value. The reason to set text item delimiters back to the old value is when you’re using handlers who has different text item delimiters set but does make an call to the other handler. Here a small example:
set theString to "replace this for that
replace this for that
replace this for that
replace this for that"
handler1(theString)
on handler1(str)
tell AppleScript
set oldTIDs to text item delimiters
set text item delimiters to linefeed
set TIs to text items of str
repeat with i from 1 to count TIs by 2
set item i of TIs to my handler2(item i of TIs)
end repeat
set str to TIs as string
set text item delimiters to oldTIDs
end tell
return str
end handler1
on handler2(str)
tell AppleScript
set oldTIDs to text item delimiters
set text item delimiters to "this"
set TIs to text items of str
set text item delimiters to "that"
set str to TIs as string
set text item delimiters to oldTIDs
end tell
return str
end handler2
If you don’t set the text items back properly the code will give unexpected results and will use the text item delimiter of the wrong handler to coerce the list into a string.
AFAIK That has always been the case, the only difference between Mac OS X and Mac OS system is that script editor will use a new AppleScript component between each compile while in Mac OS it did not. Here some code to test for yourself:
if (AppleScript's text item delimiters) as string is equal to "" then
log "new scripting component"
set AppleScript's text item delimiters to "delimiter"
else
log "same scripting component"
end if
… and the preferred/encouraged method, please?
The preferred method is to set the delimiters back to their previous value within the handler/scope they were changed. That is the only way that guarantees that operations considering them will be without unwanted side-effects at all times.
This is true. What I’m even more concerned about, is whether a new scripting component is used when a script from the script menu is run. I experienced problems with this in Tiger, but, I still believe it is up to the App Developer how they implement their own script menu, so, it is really up to them how they distribute any scriping components. That is also a reason for restoring the text item delimiters.
How you write it down can be arguable (using a tell block or not, etc) but either way it has to be something like:
set theList to {"a", "b", "c"}
return join(theList, ", ")
on join(lst, sep)
tell AppleScript
set oldTIDs to text item delimiters
set text item delimiters to sep
set str to lst as string
set text item delimiters to oldTIDs
end tell
return str
end join
Thanks DJ.
True, the reason is that one code cannot ruin the other. Script editor can run two script simultaneously by using a scripting component for each document. However, applications like QuarkXPress who uses one scripting component for all scripts cannot. Therefore scripts for the QuarkXPress scripting menu always begins with set applescript’s text item delimiters to “”. To make sure a crashed script from a previous run doesn’t ruin my code.
Have experienced that a few times, in my earlier scripting years, when writing script for QuarkXpress! 
Live ‘n’ learn!
Yes, I have started to use Smile from Satimage now, which is an ideal piece of software, if you intend on using AppleScript as a very primitive alternative to MatLab, and similiar, that is, use AppleScript as a computing enviroment, like a basic interpreter if you like. Smile now comes as SmileLab, for free, with plotting and drawing facilities, with the ability to generate pdf good looking images, for free.
Smile uses only 1 scripting component, (so libraries are loaded globally), at least for the AppleScript terminal windows, it doesn’t use AppleScript version 2.3 either, not yet anyways. But given drawing, plotting, and rs232 support -for free, I am forgiving.
Summary (pick your poison)
McUsrII’s #4 (4 lines, 4 assignments)
Nigel Garvey’s #7 (2 lines, 4 assignments + 2 lists, µsec slower) 
McUsrII’s #17 (1 line, works only the 2nd run, not recommended)
. because in that code .
set {text item delimiters, newText} to {", ", (items of ml as text)}
. “,” and (items of ml as text) are both evaluated before either the text item delimiters or newText are set. So the coercion takes place before the delimiters are changed.
On the second run (unless the script’s recompiled in the meantime), the tids are still set from the first run.
By the way, (items of ml as text) creates another list containing the same items as ml and derives the text coercion from that, whereas it’s only necessary to derive the coercion from ml itself, as in (ml as text).
Just for the record, items of ml as text was something I tried to make it work on the first run, in my Applescript Editor, I have to run this code twice in order to make it work:
set ml to {"a", "b", "c"}
set {text item delimiters, newText} to {", ", ml as text}
log newText
It works on first attempt in Smile, but, I am not totally sure, if that is because I have run the code earlier there, and that there is a common scripting component.
And it’s probably worth pointing out that it’s not just TIDs, but any property of AppleScript. If, for example, a script contains the line set AppleScript’s return to “WTF” , any other scripts might start behaving more than a tad strangely. A more practical consideration is the new progress properties.
I tried something like that, in order to make a fast one liner, I tried to assign the text item delimiters to pi, but, it turns out that pi has become read only.
Try:
set AppleScript's pi to 2
Thanks Shane, that was the correct solution to a bad idea, I oversaw that possibility, the other reason was of course, that I need an extra line to restore pi, or any other constant, -not sure if I think it is comforting that the constants aren’t read only after all though.
It was interesting to watch the Mathilda’s today.
Ouch! I don’t recall ever seeing the advice that one should explicitly set ‘pi’, the time constants, the character constants, and AppleScript’s version before using them rather than assume they had their default values! :o 
It’s not. OTOH, when was the last time you heard of someone being caught out by it, other than with TIDs?
Pity about the result…