I’ve been coming to this site for many years and thought it was time to give something back. If you’ve heard about Object-Oriented Programming and wondering what the big deal is, this is the tutorial for you.
It was about two-thirds of the way through. Sorry, but I find so many pages painful to deal with.
FWIW, I find AS’s OOP support quite intriguing. But in the end it seems to me it comes up short. And that, combined with the lack of a built-in loading method to make it usable, renders it largely of academic interest (to me). It’s a pity – but then AS is the land of pity…
2/3’s the way through is very helpful. I’m really glad you mentioned AppleScript class loaders. I actually created a way to do this and was planning on posting on this onto my blog once I hammered the details down on this post. However, if you’re interested, download from my github repository. I’m not saying it’s ‘perfect’ but I think the bones are there. https://github.com/caoimghgin/AS-OOP
There are several loaders around, and I suspect they’re quite good. But none of them are built-in, and that’s the problem from a deployment perspective – they end up being more cumbersome than things like scripting additions or helper apps (not to mention usually slower and more limited).
I guess I’m just not convinced that OOP adds much oomph to vanilla AS.
FWIW, I loved your page and hope to see more of it.
The friendly and clever approach was an entertaining read and gave me some real food for thought. I am actually transitioning into ObjC from Applescript (finding ASOC to be uglier to deal with than straight AS, I’m skipping it) and your article actually helped me clarify some of my thoughts on both AS and OOP in general. So thanks!
Yeah, when I was halfway through Pirates vs Ninjas, I was desperate for a loader. This is probably the major reason OOP isn’t used very much in AppleScript. Here’s the thing. In PvN, I wrote all of the classes in-line, meaning I just wrote everything in a single file. OOP programmers much prefer to pull those classes out into separate files. In Java, these classes can live in several places and Java will search all of these places and automatically ‘load’ the class you referred to. If you look at my github repository, I’m doing much same thing. Are the classes in the library folder? Are they next to the .scpt? Are they within a .app bundle?
Perhaps the best thing about my load solution is it’s very natural to AppleScript. However, it would have been best if the AS Environment took care of this for us.
Thanks BlueFrog! I really appreciate it. Glad people are finding it helpful!
Yup! I love hopping from file to file trying to find what this thingie does! It gives a feelin’ of frog in a swamp, hop, hop, hop, hop … funny, I think I’ve been here before…
But I understand now the loader concept. (By the way, the automatic loading is what makes it so easy to get lost in the swamp)
But maybe as is is a good thing, all the hopping destroys the greatest asset of AppleScript, it’s readability, that makes writing short scripts a joy (further than that it’s been called a read only language :lol:. Let’s face it, AppleScript was never meant to be big, but just a messenger for the big Gods written in languages for grown ups. That’s how I see ASOC: to be big, AppleScript had to change.
And then ScriptDebugger hates script objects and so does (did?) XCode.
This said I’ve been finding script objects a joy to use in modelling application objects.
Sure, there is a bit of hopping when you’re creating these classes but once you’re done. You’re done! At the end of the day you have this little jewel of code you can pop right into any project. You can share it with anybody. Anybody can make improvements to it and share it right back to you. You won’t have to modify any code in your main program - your main program will simply work better – as will any old projects and new!
Those are pretty awesome benefits but the best part (for me) is that it really cleans up the code. Check out this screen shot showing the classes stored directly in the .app bundle. If you need to modify a class, just double click it and it’s opened up in AS Editor.
The same script can be load and run from and app, and from a service, then you have access to the script from spotlight, from a short cut, from a dock folder, and from the script menu, if you like. And you edit the script in one place.
Edit I forgot to mention shell scripts.
Script objects can also be viewed as view objects.
Say you have clearly defined what your script object’s does and doesn’t, then you can have scripts on the script menu, or like me, in a products folder, that you load and run from the script menu.
Then you can have some “controller code” that just fire off, and doesn’t mediate, between the script objects, to create larger workflows, attaing full reusability.
Just so everybody is aware, I will be posting an update to the AppleScript Class Loader soon. Finally got the bugs worked out. I’ll also be sure to blog post (very short this time) and give you the details.
AppleScript class loader is done by the interpreter. Script objects can’t be handled as classes because, as the word itself say, is always an instantiated object and not a class like in other OOP. Because the ‘class’ is out of reach we can only write code, like Shane mentioned to a post of mine, that simulates OOP features but never will be one. Also we have shown how you can have sub-script-object using inheritance but again here it’s subobject and not a subclass.
A real loading mechanism will be done in the preprocessing stage of code and not at run time. Then dynamic linked libraries will be loaded and binded before executing where you in AS will load script objects at run time.
If you want to make a semi class loader you need to write a preprocessor like ASObjC uses. The problems is that you allow/generate code that can only be compiled by ScriptEditor after preprocessing (handlers and script objects needs to exists at compile time for AS). So you need to have an IDE on top of ScriptEditor.
I don’t want to discourage you or anything but we’re all aware of the drawback and possibilities of Script Objects in AS and there are is enough example code on MacScripter as well.
AppleScript is definitely not OOP! It has some of the OOP features but doesn’t make it OOP at all.