AppleScript items which can be âshared dataâ (as theyâre sometimes called) are lists, records, and dates.
If you get a listâs âcontentsâ â or more correctly its âitemsâ â the result is a new list, but it contains exactly the same items. So you can make changes to one list at the list level without affecting the other list. But if any of their items are themselves lists, records, or dates, and you make changes in those items, the results will be visible in both lists. So:
set aList to {1, 2, {3, 4, 5}}
set anotherList to aList's items -- Another list containing the same items.
set item 1 of anotherList to 8 -- Replace existing item.
set item 3 of item 3 of anotherList to 7 -- Modify existing item.
return {aList:aList, anotherList:anotherList}
--> {aList:{1, 2, {3, 4, 7}}, anotherList:{8, 2, {3, 4, 7}}}
The âcopyâ command, on the other hand, makes âdeepâ copies of the stuctures being duplicated. Any lists, records, or dates within those structures are duplicated too:
set aList to {1, 2, {3, 4, 5}}
copy aList to anotherList -- Deep copy of the list structure.
set item 1 of anotherList to 8 -- Replace existing item.
set item 3 of item 3 of anotherList to 7 -- Modify existing item.
return {aList:aList, anotherList:anotherList}
--> {aList:{1, 2, {3, 4, 5}}, anotherList:{8, 2, {3, 4, 7}}}
I was informed years ago by one of Appleâs AppleScript engineers that âcopyâ and âsetâ do exactly the same thing when it comes to immutable objects such as numbers, strings, and enums. The results are the same objects, but because they canât be modified, only replaced with other objects, it doesnât make any difference. The reason âcopyâ still takes slightly longer than âsetâ in these cases is that its underlying code has to decide whether or not to duplicate the objects!