On May 26, 2016, at 3:00 PM , has <email@hidden> wrote:
Subject: Re: functions as sort of first class objects
I thank you I thank I thank you. That is one of the most — possibly the most — informed, clear, instructive, and helpful descriptions I’ve seen anywhere about all the topics you mentioned. I’ve been AppleScripting since it first appeared. (Plus, as you might have guessed, worked very extensively in many other weird languages such as Lisp Smalltalk, as well as reasonable Smalltalk-influenced languages such as Python. However my scripts are almost always to drive application behavior, often invoked with keystroke macros. (formerly QuicKeys, currently Keyboard Maestro), rather than long application-like scripts with script objects, etc. I do collect a lot of my common code into libraries, but I don’t think I have any handlers in them that are more than 100 lines long. Sometimes I do write scripts that methodically transform something, and those can get a little bit sophisticated. I have never understood the purpose or applicability of script objects and inheritance in AppleScr It’s very difficult identifying undefined behavior in AppleScript, because everything in it is so weird that most of the time I either reuse and modify pieces of code that worked in another context or wander around until I get something working. In the process, unfortunately, as often happens with that kind of approach, is that I’ve built up mythical beliefs as well as kept mental pictures of things that have changed since I made them. One of the contributing factors is the minimalist approach the AppleScript documentation takes, though for what it is trying to do is actually very good. I think I read every AppleScript book that’d been published before about 8 years ago, but I don’t think any of them went into much sophisticated detail. What led to attempt this weird first-class object sort of thing — and gee, isn’t that what a script object is, duh? — is that I wanted to write a set of unit tests drive by a harness. Something like: to test1() … to test2() … tests = {my test1, my test2} to setup() tell app “TextEditor" set doc to make new document at the beginning of documents set the text of doc to testString return doc
end
end
to teardown(doc)
close doc without saving
end
repeat with test in tests
doc = setup()
test(doc)
teardown(doc)
end
I realize this is pushing AppleScript a bit, but I was curious to see if it could be done. The discussion before your post led to the discovery that making test global makes this work. (And by the way, although I didn’t post it that way originally, it does work with parameters as shown in the above code.) The test script is really useful. The list tests actually has about a dozen tests and I keep adding more, and finding more mistakes as well as ideas for improving the handlers being tested. It wasn’t an idle musing, though I am definitely not adverse to those.
Anyway, thanks again for your wonderful post. I will change my code to use a script object forthwith.
This came just in time, because I will be distributing the handlers with their tests soon to the Keyboard Maestro forum — the handlers actually call KM macros through KM’s AppleScript commands, so I can test the KM macros from this AppleScript. Each test puts starting text in a new TextEdit document, does stuff that involves calling one or more KM macros, gets the text of the doc, and compares it to the expected text. I will probably parameterize the initial text and expected resulting text too.
Hope the length of my posts isn’t disturbing to too many people. This is all just so juicy. |