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!