I tried to rewrite the date detector here as a handler:
-- classes, constants, and enums used
property NSTextCheckingTypeDate : a reference to 8
on getDatesHerein:thetext
set theText to current application's NSString's stringWithString:theText
set theDetector to current application's NSDataDetector's dataDetectorWithTypes:(NSTextCheckingTypeDate) |error|:(missing value)
-- find matches in string; returns an array of NSTextCheckingResult objects
set theMatches to theDetector's matchesInString:theText options:0 range:{0, theText's |length|()}
if theMatches's |count|() = 0 then error "No date found"
-- get the date property of the NSTextCheckingResults
return (theMatches's valueForKey:"date") as list
end getDatesHerein:
there is a tell block and lots happening, but then, when it comes time to do this,
If I write set myListODates to its getDatesHerein:bigplaintext the script errors with a -1708…
If I write set myListODates to my getDatesHerein:bigplaintext (I actually found this solution on stackexchange, I was shocked)… it works.
I don’t understand the difference and why it wouldn’t work with “its” … what’s the real difference between my and its?
That’s exactly right. its refers to the target of a command and my refers specifically to the current script. Where the script is the default target, they can mean the same thing, but I think it’s best always to use my where it’s the script that’s meant.
The word “it’s”, with an apostrophe, is short for “it is” or “it has”. The apostrophe is incorrect in the homophonic possessive pronoun “its”, both in English and in AppleScript. The AppleScript compiler has an amusing Easter egg which you’ll see if you compile your first example script.
There are times when it’s useful for context, such as when a word can either refer to a property of the target or can be something else of which the compiler’s aware. For instance, this won’t compile without the its:
set cd to (current date)
tell cd
set its month to December
end tell
The its tells the compiler to understand month as a property rather than as a class.
Similarly if you’re referring to a variable in a script object which has the same label as one in the current script, its can make it clear which one’s meant.
Hah! indirectly, you lead me to it – check out page 23 of @Shane_Stanley’s Everyday ASObjC book! He discusses it in there and mentions that he could have used my but that its would lead to less problems so he’s using it throughout… (!)
I was just following his examples!!! hahahahaha
Apparently, I’ve stumbled into a semantic trap here – sometimes, I can call a handler without giving AS any context. however, that wasn’t happening with this script, perhaps due to nested tells. So I was following examples from Shane’s book mentioned above, where you tell AS how to find the handler – in his book, he uses its instead of my. that is: set myBigString to its onHandler:someParameter
In all my examples so far, I’ve not seen an issue – everything runs as expected… but I did what’s above, and it would not run… this is what got me down this error -1708 thing and discovering that it should be my there!
So I’m still scratching my head on this – why did its work in the 20 other scripts just playing around, but it did not here? I can’t figure it out.
If you call a handler from within a tell block, the object being “told” thinks the call is a command to it — and of course it has no idea what you’re talking about because the handler belongs to the script, not to it. Placing its before the call visually reinforces this:
tell application "Finder"
set myBigString to its onHandler:someParameter
end tell
For this reason, I disagree with Shane’s idea always to use its. Use its (told object) or my (script) as appropriate:
tell application "Finder"
set myBigString to my onHandler:someParameter
end tell
Similarly with non-colon handlers:
tell application "Finder"
set myBigString to my onHandler(someParameter)
end tell
I think that’s the difference that I’m missing here - Shane’s examples in the book are not in tell blocks but rather the body of the script.
Now I get it (for the moment). So it was the scope issue but exactly what you are telling me — the application being told isn’t where the handler is. my forces AS to look in the script.
Thank you!
Let me restate this another way to see if I understand…
In the script body, that is outside of any tell block, the variable is inheriting the handler objects because of the script, so its works in that context because the handler is an inherited object. In a tell block, however, the variable is considered to be in the context of the application, and therefore loses any inferred (or inherited) context for the handler, so AppleScript doesn’t see the handler in the object hierarchy, and thus the application being told complains that the handler can’t be handled. This is also why calling the handler without any reference doesn’t work in the tell block – i.e. return myHandler:someVariable - because the context is in the application being told. Using the my possessive forces AS to look in the script context instead.
Calls to handlers with interleaved parameters (I think that’s what they’re called!) — ie. those with parameters preceded by colons — have to have some sort of possessive word in front of them, even when not in tell blocks. I think this is because they were introduced with AppleScriptObjC and were originally designed for calling methods belonging to Objective-C classes.
Awesome. Thanks for suffering this out with me. I get it. And that’s what Shane refers to in his book: interleaved parameters.
Coincidentally- if the call is in the script body such as: return thisHandler:passedObject
It works with no possessive. So there is some inference going on fairly well by the AppleScript. But I think you are correct - with all that we’ve said here, putting my in front of it would appear to be the best way to be sure Applescript looks in the correct place!
FWIW, Shane’s discussion on page 23 of his book has to do with the use of interleaved syntax in calling a handler, and I would not generalize that to other circumstances (where my and its are used for other reasons). Shane makes this point when he states:
If you want consistency, you can insert an its, or in some cases a my, to force the use of interleaved syntax, but you can also live with the underscores; they are not really a problem. In this book, I will insert an otherwise unnecessary its to force the new syntax, just for consistency’s case.
It should also be noted that the script Shane is discussing hasn’t targeted anything, and, as as a result, me and it refer to the same thing. Thus:
use AppleScript version "2.4"
use framework "Foundation"
use scripting additions
on cleanUpText:someText
set theString to current application's NSString's stringWithString:someText
set stringLength to theString's |length|()
set theString to theString's stringByReplacingOccurrencesOfString:" +" withString:" " options:(current application's NSRegularExpressionSearch) range:{location:0, |length|:stringLength}
set theWhiteSet to current application's NSCharacterSet's whitespaceAndNewlineCharacterSet()
set theString to theString's stringByTrimmingCharactersInSet:theWhiteSet
return theString as text
end cleanUpText:
set theResult to cleanUpText:" One two three " --> Syntax Error: Expected end of line, etc. but found “:”.
-- set theResult to its cleanUpText:" One two three " -- works as expected
-- set theResult to my cleanUpText:" One two three " -- works as expected
display dialog quote & theResult & quote
For completeness (and hopefully not to confuse you!), if a script object inherits code from another script object, the word my or its in that code refers to the script object using it at the time!
script a
property something : "Hello"
on saySomething()
say my something
end saySomething
end script
script b
-- Have this script inherit a's properties and handlers.
property parent : a
-- But give it its own 'something' property.
property something : "Goodbye"
end script
tell a to saySomething()
tell b to saySomething()
Makes sense and thank you for extending this into that scenario. That further confirms how I understand it now so you’ve helped me get to a good place! Somehow, I wasn’t seeing it at all yesterday!
Your example clearly shows where its makes a difference.
However, as far as I understand its is still not indispensable as this code will do the same:
set cd to (current date)
tell cd
set cd's month to December
end tell
P.S. Maybe because I’m not a native English speaker, its in most cases kinda irritates me because I don’t “feel” what exactly it refers to. That’s why I stick to my instead (for handler uses etc.)
By way of example:
script a
<many lines of code>
my aHandler() --> makes it clear to me that the handler belongs to the entity I'm working with (similar to *self* in ObjC)
its aHandler() --> refers to some abstract "it" entity, which to me doesn't clearly convey the handler's owner
<more code>
end script
Once again, maybe it’s just me for whom English isn’t mother tongue.
