Applescript behind on functions

After all these years, AppleScripters having been creating workarounds for doing things. My question is, why doesn’t Apple add some new Additions. Like maybe one for search and replace. Or they might add some math functions. It wouldn’t take to long for some programmer to add some things or would it?

Scripting Additions are outdated technology, because they are based on Carbon.

Take a look at Shane Stanley’s ASObjC Runner, a faceless background application like System Events.
This is the modern way to write Scripting Additions

But maybe there could be some improvements in Mavericks.

Hi Stefan,

You’re right. Actually we should be glad that Apple put out this thing called AppleScript and said do what you can with it. And, people like Shane Stanley and other writing the scripting additions did it. It just came to mind a scripting addition I used to use a lot before. Akua Sweets or something like that. It must have taken a lot of work to make that.

gl,
kel the enlightened

As Stefan says, scripting additions are old hat. And it’s not just because they are Carbon critters – they also have other negative implications, including security and application stability, and terminology pollution. They’re also not very good at maintaining state – but then, neither are faceless apps.

There’s definitely an opening for something new…

Akua Sweets, huh? That brings back memories.

The new scripting additions are like script runners.

They both have pros and cons. The fact is that Scripting Additions are far more complexer to make than a faceless application. When you would make a MySQL connector for AppleScript it’s very hard (I’ve made one myself a couple of years back, before deciding to write an XML-RPC/SOAP server). In a script runner you would create such an application within two days.

The problem with faceless apps comes when you want to maintain state, but have to be able to cope with potentially more than one client at once. Unfortunately AS’s transaction support is broken, and asynchronous stuff is hard to do with AS.

So ideally we need a replacement that is ubiquitous, reasonably fast, expandable, able to operate and maintain state preferably on a per-process basis, supporting call-backs, yet still with the familiarity and ease of use of AppleScript. Tall order? :wink:

True, but can’t that be solved by using object specifiers instead of pseudo classes (mostly)?

Tall? no not at all, It’s simply all we need ;).

Possibly – but I gave up on it.

I assume that it would be technically possible for Apple to buy ASObjC Runner as they did for some features of Standard Additions.
But I’m not sure that such a deal would give us a better support.
Shane is really reactive and efficient and I’m not sure that we may say the same about Apple engineers.

Yvan KOENIG (VALLAURIS, France) jeudi 17 octobre 2013 08:44:21

Looking at the history of AppleScript (and apple) it seems that Apple rather develop similar tools than buying tools from 3rd parties.

Hello.

I think it is bad that transactions has been broken, not that I used it much, but it was one of the things that made database eventes worthwhile to play with.

Given faceless apps, and all that: At a certain level, I really prefer Objective-C. Maybe Apple reason the same way: that at a certain level of sophistication, you should really use Objective-C anyway. (Callbacks and transaction locking between applications, amongst things.)

Edit

Some from of transaction locking, that is a must, and if you are in control of the situation, then it is not too hard to implement, and as long as AppleScript is single threaded, it shouldn’t be too hard to fix for Apple.

Partially: For inter-application communication there is no effective and easy-to-use alternative to Apple Events.

To be fair, it’s really not up to the engineers; it’s the people above them who control resources. I’m sure the engineers would like nothing better than to spend their days building snazzy new stuff.

There’s no doubt that AS has been squeezed for resources, but these things sometimes go in cycles as higher-ups come and go.

Probably the important thing is for people to make their voices heard by logging bugs and feature requests. I know I’ve been guilty of not bothering in the past, and I know lots get ignored, but I think the volume of them is still a metric those allocating resources look at.

Hello.

The one thing I don’t see implemented with AppleScript and Events, are callbacks, I see them out of the limit. It is actually quite hard to get it right, even in C.

Letting the voices be heard, and results shown, -the usefullness of AppleScript, also as a sales pitch. (Like Shane is into), is one way of getting the managment of Apple allocate resources. I have the deepest respect for Apple Engineers, (I’ll just mention Quinn the Eskimo! :slight_smile: ) As Shane said, things goes in circles. Hopefully, Apple’s product line of computers will remain as a viable enough market segment that it is worth while to pour investment into OS X and not just into those frameworks, that runs on multiple hardware platforms.

Oh ye of little faith…

Hello.

I meant callbacks, like in installing callbacks into a kext. I don’t doubt you can make it happen, if any!

I just want to add, that too me, what constitutes a Mac, is something that handles AppleEvents. So, in order to make the 80% segment of the market of Mac’s grasp that AppleScript and Events, are core technologies they crave, we should of course distribute useful scripts to them, that is, share them, when we have written them. :slight_smile:

The script menu not enabled by default, is the first bug that must be fixed on our way to a more eventful future.

I can’t understand why they hide the greatest feature! :slight_smile:

Hi,

Using ASObjC Runner is a good idea! It’s easier to download than Satimage, contains the trig functions, runs cocoa-applescript, and has the search and replace routines. I think I’ll make handlers using the ‘do trig on’ command. I couldn’t find a ‘log’ function though. Maybe there’s something in Developer Library using cocoa-applescript.

Thanks a lot,
kel

ps. Great info as always!

An oversight. Without going bananas, are there any other obvious missing items?

Not really. Objective-C is a strict superset of C, so it doesn’t bother duplicating the C maths and trig functions – to an Objective-C programmer it would mean more work for less performance. But that’s no help to us in AppleScript land. It’d be nice if there were some kind of general performFunction: method.

Isn’t easy for everyone to roll their own? Using a log file if they want it to show up in Console, in Text Edit if they are utterly lazy. :slight_smile: Or in Text Wrangler if they want to see differences between runs (with the compare two frontmost documents feature)?

And I thought it possible to implement a perform function, via introspection? perform selector? And, as for implementing trigs; that would be a nice bonus excercise in your book, implementing such a wrapper class, giving them atan2 to look at. And also “d” variants, that takes and yields degrees as results. :wink:

I’m really not entitled to have any opinion about this, because I’m too occupied to ever get my hands dirty with AsobjC, or so it seems. But idelogically I’d rather use it, alot. And I also unfairly think it best to keep the core of it as light as possible; the tighter, the faster…