Proper use of "my" in scripts

Just wondering what difference, if any, or other connotations using these 2 different ways of referring to objects might have.

For example, I know that if you want to run a subroutine inside of a tell block that targets some other external application (like the Finder, for example), you’ll have to use “my” in front of the subroutine to let the script know that you want to use a subroutine that’s part of the script, and not part of the Finder.

Is it similar to that when you’re, in the various handlers of an AppleScript Studio application, referring to other things, like properties and such that you’ve set up at the beginning of the script (are these called “global” properties?)?

Like, is it necessary in the following (extremely abbreviated) script, to use my in “set my fonts to {}” if I want to alter the value of the fonts_ property that I declared up at the top of the script (and/or which may still have items in it from an earlier run)?

property stop_processing_ : true

property fonts_ : {}
property selected_fonts_ : {}
property dropped_fonts_ : {}

-- Application Droplet
on open dropped_items_
	-- clear properties
	set my fonts_ to {}
	set my selected_fonts_ to {}
	set my dropped_fonts_ to {}
	-- process files
	my get_all_items_(dropped_items_)
	my process_fonts_(fonts_)
	return true
end open

on get_all_items_(dropped_items_)
	--blah blah
end get_all_items_

on process_fonts_(fonts_)
	--blah blah
end process_fonts_

Thanks in advance for any info…

The use of “my” becomes difficult when using script objects or complex contexts (such as properties “parent”). However, if I run a similar code to yours, there is not difference between “my fonts_” and “fonts_”. Attached to a button:

property fonts_ : {"blah"} 

on clicked theObject
	set fonts_ to {"bleh"}
	log fonts_ --> {"bleh"}
	set my fonts_ to {"bloh"}
	log fonts_ --> {"bloh"}
end clicked

Script properties are global throughout the script - or script object - in which they occur, so you don’t normally need to use ‘my’ when accessing them. However, there’s nothing to stop you using it if you want to.

One case where you might have to use ‘my’ in a handler would be if you had a local variable with the same name as one of your properties. You’d then have to use ‘my’ to access the property rather than the local. For instance, in your process_fonts_() handler, fonts_ is a local parameter variable, not the property fonts_. It so happens that you’ve passed it the same list, but it’s not the same variable. You can change an item in the list via the local and see the change with the property, but if you change the value of the local itself to, say, another list, the value of the property doesn’t change. To achieve that, you can use ‘my’ to indicate that you mean the script’s property (or global) of that name. Alternatively, of course, you can leave out the parameter variable in the first place. :slight_smile:

If your property contains a large and/or frequently accessed list, you’ll find that using ‘my’ in front of its name speeds up access to the items in the list.

item i of my bigList

-- rather than

item i of bigList

I don’t really understand the technical reasons for this, but it’s something to do with the fact that the expression ‘my bigList’ is a reference rather than a direct use of the variable name.

thanks for the info!