Shane Stanley wrote:
>> However, the current default target is only used when you
don't specify an explicit target yourself.
>
> So here's a small script. Tell me what you think it will return
with, say, a folder selected. Answer honestly before you run it.
>
> tell application id "com.apple.finder" -- Finder.app
> set x to selection
> set y to item 1 of x
> set a to class of y
> tell y
> set b to class
> end tell
> return {a, b}
> end tell
Not sure why you post this example, since it doesn't have anything
to do with targets or message dispatch.
The problem is that the 'class' keyword has overloaded semantics: it
is used both as a type name _and_ a property name. A 'terminology
conflict', in other words. In most languages such overloading of a
given name wouldn't cause any technical problems because adjoining
syntax would dictate its actual interpretation and usage in any
given context, e.g. 'b = class' vs 'b = .class'. But because
AppleScript omits crucial syntactic cues in order to appear
"English-like", in the absence of any semantic cues (e.g. my
class/class of me or its class/class of it) it has to "deduce" the
intended meaning from other available information, such as whether
it's defined as a keyword or an identifier, and if the former what
sort of keyword it is (type name, constant [enumerator] name,
property name, element name, command name, parameter name). And
since this particular keyword, 'class', has two valid meanings -
type name (cClassIdentifier='pcls') or property name (pClass='pcls')
- AppleScript then falls back to simple precedence. And for whatever
reason the AS parser likes type names more than property names, so
picks the former.
So it doesn't matter how many 'tell' blocks you wrap 'set b to
class' in: none of them will have any effect. AppleScript will
always treat the right-hand _expression_ as an atomic symbol, «class
pcls», not as an object specifier whose implicit root is the default
target, «property pcls» [of me].
You still made me stop and think for a couple minutes, you absolute
rotter you. I knew straightaway that this was one of those "funny
cases", but I've learned and forgotten so many over the years, and
having buried such hellish knowledge deep, deep down, it takes
conscious time and effort to drag it up again. It's almost certainly
in the book, mind, but whether it's explained accurately,
bullshitted, or simply presented as a fait accomplis without further
comment I couldn't say without checking. But I'll forgive you, on
condition that you now explain to the list how to use a 'date myStr'
specifier in an ASOC class without it blowing up, and why it does
explode when you try to do it same as you would in regular AS
code**.:)
has
** I recall explaining this one last year, but let's see if you can
dredge up and clarify arcane AS crap any quicker and slicker than
me. ;p
|