On 31 May 2016, at 5:43 AM, has <email@hidden>
wrote:
> > I LOLed:
> > use script "SomeFancySDEFEnabledLibrary"
> > some fancy command someLocalHandler()
> > --Error: -[BAGenericObjectNoDeleteOSAID
someLocalHandler]: unrecognized selector sent to object
<BAGenericObjectNoDeleteOSAID @0x7fabd8e19280: OSAID(2)
>
I'm not sure why you find that so surprising. What
would you expect from this?
use application "Finder"
reveal someLocalHandler()
on someLocalHandler() return "/" as POSIX file
end someLocalHandler
I would *expect* it to work the same as this:
use application "Finder"
someLocalHandler()
reveal result -- opens Finder window
on someLocalHandler()
return "/" as POSIX file
end someLocalHandler
I'm not sure why you think it could be anything BUT a serious
defect; do you understand exactly what AS is doing here and why? (Or
are you agreeing with me that it's a serious defect, and are simply
astonished that I could still expect anything other than rank
incompetence from AppleScript?) Honestly, the only surprise should
be that it took me so long to notice the problem - I'm really
slowing down. Also, I was slightly off-target [sic] describing the
behavior last time: the keyword command doesn't change the parameter
_expression_'s evaluation context[1]; the keyword command implicitly
changes the parameter _expression_'s default target to be the same as
its own target.
What on Earth gives one command the right to _dictate the target for
another, just because of how it's written? It doesn't do it when the
nested command is another keyword-based command:
use script "Text"
use script "List"
join text (sort list {3, 2, 1, 4}) --> "1234"
So why the hell should it be any different when it's an
identifier-based one:
use script "Text"
use script "List"
join text (sortedList())
...
This invisible "keyword commands implicitly redefine the default
target for their parameter expressions" behavior may not have caused
users problems pre-10.9, simply because having to wrap the entire
application-defined keyword command in an explicit `tell` block just
to get it to compile forced local commands within that block to
specify their own target too using `cmd() of me` (`my cmd()`) or
`tell me to cmd()`:
tell application "Finder"
reveal (MY someLocalHandler())
end tell
tell application "Finder"
MY someLocalHandler()
reveal result
end tell
But since the introduction of SDEF-based libraries and `use`
statements, this invisible behavior in keyword command evaluation is
no longer being masked by that extant `tell application...` block:
now it's visibly manifesting in AS code that explicitly says one
thing yet magically does another. 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, and how to meticulously
identify and avoid stepping in that man-trap in future.
This is precisely the sort of crap that happens when a programmer
(in this case Chris P) tries to be extremely clever, making
significant alterations to a system he doesn't fully understand
without figuring out all the potential knock-on effects of those
modifications before making them, nor bothering to destruction-test
the modified system once they're made. AppleScript is and always has
been a huge fragile tangled mess of obfucating smoke and magic
mirrors: it takes an expert magician just to USE it safely and
predictably, never mind make fundamental alterations to its entire
Act without bringing the whole lot crashing down[2].
Regards,
has
[1] Too much time thinking in kiwi, where handlers are allowed to
dictate how and where commands' parameters get evaluated. But kiwi
is a Lispy, mostly declarative language that generally tries to do
what you mean, not a rigidly imperative Algol-derived language that
does precisely what you say. I broke kiwi a few months back in a way
that caused commands passed as parameters to be evaluated in the
wrong context, causing very similar [mis]behavior. But I wasn't
foolish enough to think this anything but a Severe Bug and revert
that change (which was an experimental modification done to see what
behavioral improvements/problems it could cause) as soon as I
noticed the unintended consequence.
[2] And you wonder why veteran AS devs like me and Mark A get
terrors at the mere thought of the current AS engineers dicking
around with its fundamental architecture like this? It's cos we're
the ones who get to mop up the consequences, cos its our work their
mistakes hit first. Can't speak for Mark, but my canary days are
done.
|