This is true. This is also true for for iOS and Mac OS developers and has been so for a long time. But it is certainly something that can be managed.
In AppleScript there are a lot of scripts written for a small group, a company, for a family, … For these it is almost always know what the minimum system level is before even starting on a script. For this situation if it runs on the oldest system then you’re good to go.
The main thing is that system versions are not as much of a problem unless you sell software to the public. There are a lot of scripters that create scripts to be used on a known minimum Mac configuration. When I wrote things for companies I always knew the minimum system configuration every time. So I literally ran functional tests on the oldest system level first and then finished my testing with various version levels.
I wrote scripts that interfaced with a lot of UNIX systems and other larger systems that produced output that the Mac worked with. The data configuration was always changing. So I just wrote a script that was easy to change. I added preferences when so the specification of the data being received could be specified and allow both old and new data could be accessed. The point I am making is that system levels and configurations are very manageable. Selling scripts on the open market is when it gets hard. If I’m selling to the public I can just developed something on the oldest system that will be used.
When it comes to Apple deprecating things that is something that all scripters would have to worry about. But again this can managed just like Apple developers do. It’s true you don’t know what will be deprecated but it is not like every year a large percentage of ASObj-C methods are deprecated. Right now I see a lot of methods and constants being deprecated and then brought back with a new name. All that is needed is to check the OS version and then use the old or new version depending on the OS version number. These particular types of changes leave the interface to the new and old way the same.
I’m not sure what your point is here as far as deprecations and minimum system configurations is. Is this a call for caution, a warning of danger or just some thoughts on something. I got the feeling it was a warning of danger but I I’m not sure.
It was a heads-up for people new to ASObjC. For the most part, you can write AppleScript scripts without ever having to think about dependencies; you loose that innocence once you start getting into ASObjC.
That’s what confuses me. The problem with ASObj-C is that it isn’t documented beyond a few notes here and there and a couple of longer sources. Therefore ASObj-C has a high curve. Shane’s book makes up a considerable portion of the documentation out there and that’s just one book. Learn AppleScript: The Comprehensive Guide to Scripting and Automation on Mac OS X is the only other Applescript book I’ve seen it mentioned in and it has some useful stuff in the last chapter. There was one other book but that book ended with some passing remarks about ASObj-C and was so tiny I couldn’t take it seriously.
That is the whole reason I started the ASObj-C database. It was to get rid of the steep learning curve. Changing languages won’t make a difference when dealing with OS versions when you know the oldest OS version.
Applescript has dependencies. Perhaps not as complicated as those in Objective-C. AS has libraries that need to be present to do certain things, frameworks that have to be “used,” objects need to exist before they can be worked on, … It seems like the same mental process to me. There is just a lot more of it in Objective-C and it is true the ASObj-C dependencies are less familiar to newer users.
If something breaks in a future OS release for ASObj-C then the scripter might have to find something new for a line in the script. But that’s just like scripting additions going bad with a new OS release, Apple deprecating something used in shell script, something called in an application that no longer works in a new version of the application, the code for scripting the interface of an application doesn’t work with a new version of the application, … How is the concept of making changes for new versions of things new to a scripter? It’s been with AppleScript from the beginning.
I think you answered you own question. As you say, ASObjC has “more of it”, “ASObjC dependices are less familiar to newer users” and “ASObjC isn’t documented” - although to be fair, it doesn’t need to be. What you need to do with ASObjC is look at the Cocoa docs. Scripters, insofar as they’ve ever bothered to look at docs, aren’t likely to get much further than the AppleScript Language Guide. Warning them that they need to look further afield, and more often, is pretty much all I was saying. There’s no big headline.
Ok, I would have to agree with that. I have taken to reading a lot of Cocoa documents any more and being a scripter I have to admit I really, really hate it. But it’s about being able to do new and better things or just doing the same old limited stuff.
Your remarks are good for me. You are the only one I converse with that talks about the short comings of AppleScript and you have a different perspective then most since you have been a scripter and a developer. Thanks for the thoughts
On that note, if you haven’t already, do your sanity a favour and buy Dash. Apple’s attempts to provide an interface for their docs - both webwise and within Xcode - are not fit for purpose.
I got Dash while beta testing for SD 6.0 was going on. I updated to version 4.0 when it came out. I really like the the “Inherits From” part at the top of the class documentation. The layout of the side bar is a nice way to got to various sections for the different methods, but I really like that I can see them all laid out in a list instead of going from one to the next use the searches “find next.”
Shane,
I went ahead and paid for dash because I didn’t like the automatic delay.
Here is an installation script application form MarksLib (and MarkdownLib). This application makes installation simpler and avoids having to copy and paste commands into Terminal.
Little bit of strangenesses. (Not involving the new version of MarksLib, but an older version).
The bug is that when you try to open a library’s dictionary from a script and there is an error, the SD error dialog is whacked the first time it displays.
I wanted to see if the library had a dictionary. It doesn’t, but the way SD reported that is the problem.
I ran a script that opens library dictionaries (below). When a selected script doesn’t have a library SD’s error window should appear. In this case the first time the error dialog appears it’s blank. No text, no buttons, just an empty rectangle. If I hit return the text and buttons appear briefly and then then the error dialog disappears. If I try a second time it works as expected. If I quit and relaunch SD I get the same blank error dialog on first attempt.
I have two versions of Mark’s Lib, and its the older one (.scptd) that appears in the choose from list and doesn’t open a dictionary.
MarksLib.scpt
MarksLib.scptd
(Also, After I download the install app I can’t open it in SD because it’s from an unknown developer. )
–>Script Debugger 6.0.7 (6A213) on Mac OS 10.11.6 (15G17023)
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
set scriptLibrariesFolder to path to library folder from user domain as text
set scriptLibrariesFolder to scriptLibrariesFolder & "Script Libraries:"
set myScriptLibraries to my GetFileNames(scriptLibrariesFolder, "scptd")
set listTitle to "Script Libraries"
set listPrompt to "Which script dictionary would you like to try to open?"
set okbuttonName to "This One"
set multipleSelections to true
set emptySelectionAllowed to false
tell application "Script Debugger"
set userChoice to choose from list myScriptLibraries ¬
with title listTitle ¬
with prompt listPrompt ¬
OK button name okbuttonName ¬
multiple selections allowed multipleSelections ¬
empty selection allowed emptySelectionAllowed
end tell
if userChoice is false then return
set scriptList to {}
repeat with thisScript in userChoice
set the end of scriptList to ((scriptLibrariesFolder as text) & thisScript as text) as alias
end repeat
repeat with thisScriptLibrary in scriptList
tell application "Script Debugger"
set myLib to open thisScriptLibrary showing script dictionary
end tell
end repeat
on GetFileNames(folderWithFiles, fileExtension) -- @other stuff
--SecondLine
set folderWithFiles to POSIX path of (folderWithFiles)
set thePaths to current application's NSFileManager's defaultManager()'s contentsOfDirectoryAtPath:folderWithFiles |error|:(missing value)
set fileNames to (thePaths's pathsMatchingExtensions:{fileExtension}) as list
return fileNames
end GetFileNames
I ran into one snag that you might want to make note of in your MarksLib.applescript file.
Since you store it as a text .applescript file on GitHub, it has to be compiled before using as a script lib. The first compile works fine. But if you compile it again, you get an error because the source code has been changed: «class from»
is changed to from
on containerOf(theObject)
# return «class from» of (theObject as record)
return from of (theObject as record)
end containerOf
I remember addressing this issue somewhere, but I cannot seem to find it. Yes, you cannot compile the script twice; you have to restore the «class from» before compiling each time.
I ran into an issue in Excel where the term “color” was morphing from the needed «property colr» into «class 1097», requiring restoration of the original raw syntax before every compilation.
I got tired of the nuisance and used run script to execute the command as a string. Not sure if this is a good or bad idea, but in the case of MarksLib, it might look like this:
on containerOf(theObject)
run script “return «class from» of (” & theObject & " as record)"
end containerOf
Stan, I like your idea, but I don’t think it will work. Your script forces “theObject” to convert to text value, and will fail on a line like this: set thePerson to MkLib's containerOf(contents of anItem as record)
You’re right of course. As given, my solution does work with variable and handler names, numbers, lists and records that don’t contain strings, raw syntax, and a good bit of AS and application terminology. One could convert strings (or lists and records with strings) to a text format that would work with run script, but that adds complexity and fragility.
References, script objects, and other complex objects. are completely beyond the scope of run script. Use the trick where you can and live with situations where it doesn’t, I guess. And I’m still not sure how wise it is, even when it does work.
