On 26 Mar 2015, at 10:05 am, Stockly, Ed <email@hidden> wrote:
How about basic AppleScript; or bare bones appleScript? Or Standard
appleScript? In the old days we used plain vanilla applescript (only the
Osax included in the standard additions) and French vanilla appleScript
(also includes Jon's Commands, satimage and maybe a couple others)
I'm still not sure where the need to make this distinction is, other than perhaps for things like rosettacode, where it's more an intellectual exercise -- and in that case I think you need to spell out the limitations exactly anyway.
In a practical context of posting scripts as solutions to a problem, it seems to me the real parameters are whether third-party components are allowed or not, and whether it's Mavericks or later and can therefore use newer capabilities like ASObjC. Then there are minor issues with other changes made with OS revisions. When there's more than one solution, performance will sometimes be a good determinant.
That ignores things like personal preference and comfort-level. But they're largely *personal* things, and vary considerably. For example, for a long-time scripter this might look confusing:
capString("Frédéric Fromentin") on capString(aString) set theString to current application's NSString's stringWithString:aString return (theString's uppercaseString()) as text end capString
There's new stuff for them here, and the understandable first reaction will probably be something along the lines of, "Do I really need something else to think about?"
But consider a newcomer, and these two bits of code:
on replaceText(theString, theFind, theReplace) considering case set saveTID to AppleScript's text item delimiters set AppleScript's text item delimiters to {theFind} set theBits to text items of theString set AppleScript's text item delimiters to {theReplace} set theString to theBits as string set AppleScript's text item delimiters to saveTID end considering return theString end replaceText
And:
on replaceText(theString, theFind, theReplace) set theNSString to current application's NSString's stringWithString:theString set theNSString to theNSString's stringByReplacingOccurrencesOfString:theFind withString:theReplace return theNSString as text end replaceText They do the same thing, but which is clearer? It's a cherry-picked example, but the truth is that neither is particularly clear unless you understand the relevant syntax. Calling one un-usable before Mavericks -- now that's a useful distinction. Calling one slower is also useful, if the difference is significant. But calling one vanilla smacks more of some kind of value judgment -- it states the obvious, but it doesn't shine any useful light on things. For the purposes of Rosetta, some of the Algorithms are done with
AppleScript with no apps, osax or frameworks. Just the simple language.
Some are handled with Osax calls, some with finder calls. And pretty much
all of those can run in any version of Mac OS X.
Right. I think it makes sense to set parameters for an exercise in algorithms like this. If it were me, they'd be something like: do it in built-in AS that runs back several versions of the OS if possible, if not, allow Standard Additions but not do shell script. Beyond that, I think the exercise becomes not "how it would be done in AS" but "see, AS can do it", and with AS and it's remit, I think that's all a bit pointless.
It seems that ASObjC adds a new level of language and capabilities that go
beyond what appleScript could ever do on its own.
And as such, it seems to me pointless in these sorts of algorithmic exercises.
|