Re: JavaScript for automations: bug or correct behavior
Re: JavaScript for automations: bug or correct behavior
- Subject: Re: JavaScript for automations: bug or correct behavior
- From: has <email@hidden>
- Date: Tue, 20 Jan 2015 21:13:46 +0000
David Steinberg wrote:
>> So, in general, standard addition stuff like buttons will be arrays
starting at 1, it that correct?
>
> This will depend on the individual addition, but whatever index you
would pass in for AppleScript should also be passed in for JavaScript.
Let's be clear: like AppleScript's list values, JavaScript's Array
objects are native to that language only. Neither have *anything* to do
with how scriptable applications' object elements - or, as in this
instance, scripting addition commands - operate. For users to understand
all these technologies correctly and use them effectively, it's
essential that the boundaries between the <language> and Apple event
worlds are clearly defined and fully explained.
That Mr Nebel and you tried to make JXA all "helpful" and "familiar" by
obfuscating Apple events' own one-indexing and one-to-many relational
semantics with fake zero-indexing and all the bullshit about "element
arrays" and "ArraySpecifier" hasn't made JXA any easier for users to
understand. It's only made it more difficult and confusing instead
because now users have no damn clue what behavior to expect where -
precisely the reason programmers hated AppleScript in the first place!
(I don't blame you for this as you're a novice to this stuff; but Chris
really should have learned by now given his last attempt didn't work out
any better.)
BTW, saying "whatever index you would pass in for AppleScript should
also be passed in for JavaScript" is one of those rabbit-hole phrases
that gets ever more confusing and wrong the further you go. For instance:
AI = Application('Adobe Illustrator');
// build specifier identifying front document
ref = AI.documents.at(0);
// ask AI for the document's index number
idx = ref.index();
//--> 1 — uh-oh... (AI, like all AE-aware apps, uses one-indexing)
// now use that index number to build another specifier to the document
ref = AI.documents.at(idx);
//--> AI.documents.at(1) — oops, specifier now points to second
document!
I learned this lesson the hard way on my first appscript implementation:
soon as you try to screw with AE semantics, AE semantics screw you right
back. There's a reason the JavaScriptOSA reference implementation I sent
Sal *always* accurately preserves and presents native Apple event
semantics, and its documentation states clearly where Javascript-style
"shortcuts" are *also* provided as a convenience:
var AI = app('Adobe Illustrator');
var ref = AI.documents.at(1); // users can use native AE semantics
var ref = AI.documents[0]; // OR JS-style shortcut as appropriate
var idx = ref.index(); //--> 1
AI.documents.at(idx);
//--> AI.documents.at(1) // produces the same specifier, yay!
That Sal and the rest of you never even thought to ask me *once* why I
designed things this way and not that way I did was your choice. But
hey, I only spent thousands of hours in the last decade researching,
writing, testing, documenting, and supporting the only successful,
production-quality Apple event bridges created in the last 20 years, so
what do I know...
has
--
"It’s a curious thing about our industry: not only do we not learn from
our mistakes, we also don’t learn from our successes." -- Keith Braithwaite
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden