Re: Is AppleScript's OOP 'prototype-based' or 'class-based'?
Re: Is AppleScript's OOP 'prototype-based' or 'class-based'?
- Subject: Re: Is AppleScript's OOP 'prototype-based' or 'class-based'?
- From: has <email@hidden>
- Date: Tue, 11 Dec 2007 19:00:31 +0000
Brennan wrote:
I've heard it mentioned that AppleScript has a 'prototype-based' OOP
implementation (similar to javascript), rather than being 'class-
based'
(like Java).
AS supports prototype-based OOP via script objects, yes. The one thing
that all p-OO languages do all have in common is that there's no class-
object distinction; all you have is objects.
Beyond that, the particular approach taken by AppleScript is a bit
different to most other prototype-based languages. In keeping with
AppleScript's minimalist design, it also lacks more advanced features
often found in other such languages. As noted below, AppleScript's
system relies on making true copies of objects whereas most p-OO
languages prefer to share as much state as possible between parent and
child objects (for efficiency and other reasons). AppleScript's system
is also relatively static compared to other p-OO languages; again,
more on this below.
Well. It's true that you can do stuff like this:
[...]
...i.e. adding additional handlers to existing script objects,
You can, but you really shouldn't. AppleScript wasn't designed to
support this sort of thing, and moving handlers between script objects
screws up their static bindings resulting in hard-to-spot bugs.
Still, it's not possible to add additional handlers and properties to
script objects willy-nilly.
Again, AppleScript's particular take on p-OOP is a bit different to
most other prototype-based languages. Given the market it's aimed at,
I don't have any objection to its simpler, more static, locked-down
approach here.
That strikes me as being much more like 'class based' OOP, because the
structure must be declared in advance of any instantiation.
No, there are plenty of class-based languages that allow you to modify
a class's structure at runtime. Static-vs-dynamic and class-vs-
prototype characteristics are orthogonal to one another.
And as far as I know there's no way of changing the 'prototype' of
existing objects.
No. This is another area where AppleScript differs from the more
common practice, in that creating new objects really does involve
making a completely new, completely independent copy. The 'clone'
method in most p-OOP languages is actually a misnomer, since the
'cloned' objects actually remain tightly connected to and share their
default state with their prototype. Thus, if you change the
prototype's state, this change is also seen in its clones unless those
clones have previously assigned their own values to these slots.
All you can do is insert new objects into the
inheritance chain (by setting 'parent'), which is a different kind of
manipulation altogether. No?
No, you can't change the parent property once a script object is
created as it's read-only. You can specify any object as a script
object's parent when you create it though (although in practice you
should avoid using anything other than the default AppleScript object
or another script object as things get rather confused otherwise).
In reality, of those very few people that do any OOP in AppleScript, I
dare say most define the script objects before compile time, and
refrain
from inserting new handlers later. Very much a class-based approach.
Yes, all script objects' structures must be defined at compile-time.
But again, static-vs-dynamic and class-vs-prototype characteristics
are orthogonal to one another. Being relatively static doesn't make
AppleScript class-based any more than being highly dynamic makes Ruby
prototype-based.
What are your OOP habits in AppleScript?
These days I don't write sizeable enough AppleScripts to need OOP; any
complex scripts I write in Python or Ruby using appscript for any
application scripting stuff.
I was doing a bit of OOP in AppleScript a few years back, however; see
<http://applemods.sourceforge.net/> for some examples. e.g. The Types
library uses some fairly simple OOP; the Loader library is a bit more
advanced.
One thing I will say is don't try to be clever with it. OOP in AS
works best when you approach it on its own terms. Keep code simple and
straightforward, and avoid fancy trickery to make it do the more
advanced stuff it wasn't designed to, since that leads to reliability
and maintainability problems. (If you want to do highly dynamic p-OOP,
go use a language like Io or something that's designed for it.)
Oh, and one other thing: *absolutely avoid* using the 'copy' command
to clone existing script objects (although using it to clone the top-
level main script, should you ever need to do so, is okay). The reason
for that is that 'copy' is extremely greedy, and will duplicate not
just the script object it's called on, along with all the values it
contains and all of its parents. And since every script object's
penultimate grandparent is the top-level script, that means calling
'copy' on any script object makes a completely new and independent
copy of your main script in the process, which in addition to messing
up any state that you do want shared also results in massive amounts
of CPU- and memory-hogging data duplication and, ultimately, program
crashes. Stick to defining script objects in constructor handlers and
only make new copies by running those handlers.
I find that I rarely use it for shorter scripts, and almost always
use it
(or end up using it) for larger scripts.
That suggest to me that yes, OOP really does help to manage
complexity,
and yes, it is too much faffing around if you need to get a simple job
done quickly.
Yes. Although this is true in any language.
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden