• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [FYI] more sdef-based library stupidity
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FYI] more sdef-based library stupidity


  • Subject: Re: [FYI] more sdef-based library stupidity
  • From: Shane Stanley <email@hidden>
  • Date: Fri, 03 Jun 2016 23:29:13 +1000

On 3 Jun 2016, at 6:33 PM, has <email@hidden> wrote:

do you understand exactly what AS is doing here and why?

I was tempted to ask you the same question. But then you gave me the answer:

I was slightly off-target

if you mean wrong, yes.

Messages are dispatched to the direct parameter by default. So here's a lib script:

use scripting additions
use framework "Foundation"
use framework "AppKit"

on some fancy command x
set thePath to POSIX path of x
set aURL to current application's class "NSURL"'s fileURLWithPath:thePath
current application's NSWorkspace's sharedWorkspace()'s activateFileViewerSelectingURLs:{aURL}
end some fancy command

And calling it like this fails:

use script "Hysteria"

some fancy command someLocalHandler() 

on someLocalHandler()
return "/" as POSIX file
end someLocalHandler

The error says something like "«script "Untitled"» doesn’t understand the “someLocalHandler” message." but the offending object is in fact the library. This also fails the same way:

tell script "Hysteria"
some fancy command someLocalHandler()
end tell

on someLocalHandler()
return "/" as POSIX file
end someLocalHandler

This works:

use script "Hysteria"

someLocalHandler()
some fancy command result 

on someLocalHandler()
return "/" as POSIX file
end someLocalHandler

This script also fails:

use application "Finder"

reveal someLocalHandler()

on someLocalHandler()
return "/" as POSIX file
end someLocalHandler

As does this:

tell application "Finder"
reveal someLocalHandler()
end tell

on someLocalHandler()
return "/" as POSIX file
end someLocalHandler

But not this:

use application "Finder"

someLocalHandler()
reveal result

on someLocalHandler()
return "/" as POSIX file
end someLocalHandler

Of course most users already knew what was going to happen with the last three. And I'd wager most of them would expect something similar to happen when addressing script libraries that use terminology, which, surprise, surprise, is what happens.

So put your expectations aside for a moment, and tell me exactly how this squares with your statement:

 This is very bad for users: you cannot teach them that the language Works This Way and then have it magically turn around and do something completely different instead with no indication, explanation, or justification why. It violates their whole mental model of how the system works; confuses, angers, and frustrates the hell out of them; and consumes a ton of their time and energy figuring out for themselves precisely how, where, and why it isn't doing *what they're damn well telling it to do* but instead doing something else entirely

Now I know there are lots of frustrating inconsistencies in AppleScript, but I'm damned if I can see how the average scripter will see this as such a case.

And you wonder why veteran AS devs like me and Mark

Please skip the argumentum ad verecundiam...

Can't speak for Mark

Exactly.

-- 
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>

 _______________________________________________
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

References: 
 >Re: [FYI] more sdef-based library stupidity (From: has <email@hidden>)

  • Prev by Date: Re: [FYI] more sdef-based library stupidity
  • Next by Date: Re: [FYI] more sdef-based library stupidity
  • Previous by thread: Re: [FYI] more sdef-based library stupidity
  • Next by thread: Re: [FYI] more sdef-based library stupidity
  • Index(es):
    • Date
    • Thread