Applescript "contents" vs "content" on a note item
Groxx
there is somewhat lacking. If you're on there at all, and / or want a
nicer display: http://is.gd/8F0yW
So, a re-post:
In an attempt to export my data, I've been poking around with
AppleScript, learning the language, etc, and currently have this:
--------------------------------
tell application "Yojimbo"
repeat with EachNote in (note items in library)
display dialog (content of EachNote) as string
end repeat
end tell
--------------------------------
What's confusing me is that, though the class in the Applescript
dictionary defines the property "contents", I have to use "content" to
retrieve the contents. Using "contents" results in this error:
--------------------------------
Can’t make «class YNot» id "A0C9E19E-3106-44F9-97A6-A1A74AD77948"
of application "Yojimbo" into type string.
--------------------------------
I'm assuming the "syn content" means it's a synonym, thus I should be
able to use "content" and "contents" interchangeably. But apparently
the synonym works, but the original does not...?
Also, more simply, why do the contents have to be coerced into a
string? If I look at the properties on the object (via: (properties of
EachNote) as string ), "contents" is a double-quoted string, though I
realize this isn't necessarily "proof" that it's a string.
I'm still starting with AppleScript, so if I'm making a n00bish
mistake, feel free to slap.
Jim Correia
> What's confusing me is that, though the class in the Applescript
> dictionary defines the property "contents", I have to use "content" to
> retrieve the contents. Using "contents" results in this error:
“contents" is the recommended name for that property, yet can be problematic in certain situations.
Longer answer here: <http://www.mail-archive.com/yojimb...@barebones.com/msg00438.html>
- Jim
Groxx
Applescript? If that's the case, may I ask why people don't consider
"contents" to be a reserved keyword (even if it's not)?
Jim Correia
On Feb 22, 2010, at 9:57 AM, Groxx wrote:
> Aaah, so this problem exists for any "contents"-named property in
> Applescript?
I tried to explain clearly in the message I linked to.
The “problem” exists when you want to access the contents property of a reference stored in a variable. (You get the contents of the variable.)
> If that's the case, may I ask why people don't consider
> "contents" to be a reserved keyword (even if it's not)?
The Scripting Interface Guidelines recommend that contents be used as the name for this particular property because it is the most natural name. (And this problem is specific to AppleScript - you can script applications using other technologies.)
I sought specific clarification from the author of that document, and it is both the author’s general recommendation, and this specific situation.
The content synonym is provided to easy the pain a bit.
Jim
Groxx
>
> The “problem” exists when you want to access the contents property of a reference stored in a variable. (You get the contents of the variable.)
/me re-reads and runs a few tests
Ah, I see, I missed the in-a-variable part. But it still strikes me
as strange (though I agree with the "most natural name" part). Every
other property collapses through any chain of variables, but
"contents" changes if it's in a variable.
So, yes. This exists for every object with a "contents" property
(when stored in a variable), at least in Yojimbo and the AppleScript
Editor dictionaries. That's *exceedingly* strange, given that
"contents of variable" == "variable" even with the examples, so why
even have "contents of variable" behave differently? E.g., given the
applescript editor example: "set d to document 1", then "d" ==
"contents of d", but "d" != "contents of contents of d"? That's a
*complete* language Fail. b(a) == a, but b(b(a)) != a? WTF.
Even weirder, if I do this:
---------------------------------------------------
set varb to {text:"text", contents:"contents"}
set x to varb
contents of varb
---------------------------------------------------
I get "contents", not {text:"text", contents:"contents"}. So
"record" behaves logically, but not objects in dictionaries? If
anything, an object *is* a map/hash like "record" that you can
duplicate, and has functions in place of some variables (or can you do
that in a record, too? equivalent to function pointers, maybe?).
Are there any other property names that have similar problems? Or is
contents unique (which makes it stranger yet that it behaves like
this)?
I wonder if I can submit this as a bug. I forget what property of
math that is, but it's pretty fundamental and it makes no sense to
break it.
Jim Correia
> I wonder if I can submit this as a bug. I forget what property of
> math that is, but it's pretty fundamental and it makes no sense to
> break it.
You can, but these things are very difficult to change without breaking compatibility with existing scripts. (AppleScript has a long history.)
Relatively recently, the AppleScript team tried to tackle this problem, but due to the issue of needing to maintain backwards compatibility, little could be done.
- Jim
Groxx
Well, thanks for all the help! Googling has been uncharacteristically
fruitless on this, so this has literally been the *only* source for an
explanation of this I've seen.