Re: functions as sort of first class objects
Re: functions as sort of first class objects
- Subject: Re: functions as sort of first class objects
- From: has <email@hidden>
- Date: Thu, 26 May 2016 16:09:27 +0100
Axel Luttgens <email@hidden>
wrote:
> Le 26 mai 2016 à 01:44, Mitchell L Model a écrit :
>
> […]
>
> I would love to hear an explanation of this, though I realize I am heading away from AppleScript life as we know it on this one.
>
> […]
I guess all of this goes more about syntactic matters; my theory is as follows… ;-)
Properties and handlers are top-level entities of a script (for such purposes, handlers may even be viewed as a special case of properties); the parser views a statement such as "g()" as a handler invocation when symbol "g" itself is recognized as a top-level entity.
Well, no: the compiler *always* recognizes `g()` as a command
because syntactically that's what it is. And it always sends it to
the current default target if not explicitly qualified with an
object specifier itself (e.g. `myObj's g()`). The OP's problem is in
mistaking AS's handlers for callable function objects, which they're
not. AS handlers are not callable objects, and messages do not get
sent to handlers. Messages are sent to script objects (or
application objects, when sending remote instead of local messages),
and its those objects that look up their correspondingly named
handlers and invoke them (if found). It's the same dispatch
mechanism as found in Smalltalk (which is one of AS's influences).
Thus, as you say, the fact that assigning a 'handler object' to a
top-level variable lets you 'call' that handler is simply an
accident of AppleScript's (terribly sloppy) implementation.
Everything you observe here is undefined behavior – i.e. it's not
what the language is designed to do or intended to be used; it's
just stuff that various users have accidentally stumbled on while
screwing around with it, and gotten the idea that it might be useful
without realizing that there might be a ton of reasons that just
because a language _lets_ you do a thing doesn't mean you _should_.
I mean, go try writing C code that exploits its numerous undefined
behaviors and see how far that gets you: if the C compiler doesn't
up and kill you other C developers – or worse, your users – will,
because deliberately exploiting this crap can, will, and does up and
bite you and them in the ass.
The *correct* way to parameterize behaviors in AppleScript is
extremely simple: you *wrap your handlers in script objects* and
pass those:
script DoThis
to doGreeting(userName)
say "Hello " & userName
end doGreeting
end script
script DoThat
to doGreeting(userName)
display dialog "Hello " & userName
end doGreeting
end script
script DoNowt
to doGreeting(userName)
-- does nothing
end doGreeting
end script
-- etc...
repeat with objRef in {DoThis, DoThat, DoNowt}
objRef's doGreeting("Bob")
end repeat
Everything works correctly, everything works as designed, everything
works as documented. AppleScript is already effectively unlearnable
and hideously brittle and easy to break: why exacerbate that by
making it do things it isn't designed to do when it already provides
a perfectly good, safe, *documented* way to achieve your desired
result? The bloody thing's already a giant friable disaster just
looking for excuses to blow up on users—why you pull the trigger
too?
has
|
_______________________________________________
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