|
On 20/01/2016 01:10, Stockly, Ed wrote:
Not sure how a handler in a variable is on a different level
of sanity or insanity than an ordinary handler.
Your `call` handler, where the handler object is bound to a *local*
variable, `someHandler`:
on call(someHandler,
aValue)
someHandler(aValue)
end
call
If you got that to work then, congratulations, it's not every day
someone manages to flummox me about AppleScript. :p
The only way to invoke a handler bound to a local variable is to do
what Chris P did, which is to invoke it again by name:
on foo()
end foo
set bar to foo
bar's foo()
Which, semantically speaking, is gibberish ("Yo dawg, I heard u like
Handlers"), and pretty obviously an accidental behavior arising from
the way AppleScript is implemented internally. But computer nerds,
especially bored corporate devs, love playing with exciting
novelties rather than doing boring old drudge work, which is why the
discussion keeps on going. As I said to Chris it'd be quicker just
to implement first-class closures correctly and then talk about
that, although as I also said it'd be infinitely more valuable to AS
users if he dealt with more practical needs such as basic text
manipulation commands and lists that don't make users' scripts run
slower than molasses.
Meantime, if users want fancy language features like closures and
generators and coroutines and the rest, there's at least a dozen
other polished, robust, popular languages out there that provide all
this stuff; no need to turn AppleScript into another C++ just to
satisfy some abstract "need" that 99% of AppleScripters will never
know nor care about. Honestly, AS has had script objects (a powerful
feature) since it was released, and look at how many ASers ever use
those for OOP, callbacks, remote code execution, and so on. If it
weren't for ASOC making them somewhat relevant to ordinary ASers,
they wouldn't use them at all.
AS doesn't need more "advanced" features: it needs more *basic* ones
(find and replace, sort list, etc) and a damn good scrubbing to
eliminate as much of the horrible inconsistent hairiness and
accidental complexity it's accumulated over the last 20 years as
possible (the whole alias/file/«class furl»/«class bmrk»/HFS/POSIX
mess being a typical example; eight different syntaxes for sending
commands another). It's a decade since AS 2.0 was released; perhaps
it's time to consider what could be practically done for an AS 3.0.
Even if it did the Python2-to-Python3 thing of breaking some
backwards compatibility in order to really tighten up the core
language and make it as good as it can be, I think that would be
well worth considering.
Regards,
has
p.s. If Chris really wants a "clever" meaty challenge to sink his
teeth into that *will* be of great benefit to users, he should fork
and reimplement AS's 'compiler' as an incremental AS parser library
which editors such as Script Editor can use to provide instant
as-you-type code-coloring, auto-completion, "What is this?"
tooltips, and all the other excellent and extremely
*end-user-friendly* code editing features that other language users
are coming to take for granted. (Although one does wonder if it
wouldn't just be simpler to write a brand new language from
scratch...)
|