Re: ASLG page 326 - Script Objects
Re: ASLG page 326 - Script Objects
- Subject: Re: ASLG page 326 - Script Objects
- From: has <email@hidden>
- Date: Tue, 23 Apr 2002 22:38:26 +0100
nicolas descombes wrote:
>
In "AppleScript Language Guide" page 326, it's written :
>
>
"A handler within a script object definition follows the same syntax rules
>
as a subroutine definition. Unlike a subroutine definition, however, you can
>
group a handler within a script object definition with properties whose
>
values are related to the handler's actions."
[insane ASLG gobbledegook translator ON]
"You can use script objects to do Object-Oriented Programming in AppleScript."
[insane ASLG gobbledegook translator OFF]
It took me about three months to understand what the ASLG was trying (and
failing) to get at. Eventually I learned the general principles of OOP from
other sources, then went back to the ASLG and figured out the AS-specific
details from that. So don't feel bad.
--
>
I don't understand the difference. Could someone give me a concrete example
>
showing "a handler within a script object definition with properties whose
>
values are related to the handler's actions".
In OOP, data and the functions which act upon it are encapsulated in a
single object. This is different to procedural programming, where your data
is floating around loose, and you pass it into separate functions to do
stuff to it.
Why would you want to bind your data and functions together? Well, back in
the days before OO languages hit the big time, programs were starting to
get big. Really big. And complex. Unmanageably complex, even. Not to
mention late. So when OO came along, some bright sparks realised that it
might be a very useful tool for making some of that complexity more
manageable.
Which it does, because:
- instead of having to think about two separate things: data _and_
functions, you only have to think about one; objects.
- you no longer have to remember which function should be used on what
data, because the appropriate functions are already bound to the relevant
data.
- objects are self-contained, which means they are wonderfully portable and
self-sufficient. You no longer find yourself creating a piece of data at
point A in a program and sending it to point B to be used, only to have to
send it back to A halfway through because there's a function over there
that I need to use on it... etc. Instead, the functions and the data travel
together wherever they go, so you always know where to find everything.
It can all be marvellously convenient, in other words. I say "can be"
because, in the end, you've still got to sit down and design this stuff
well first. A bad OO design will surely drive you every bit as nuts as a
bad procedural design. Best to start with something modest, and learn and
practise gradually, over time, rather than trying to dive straight in at
the deep end on some Uber-project.
But when you start chucking around lots of complex data of lots of
different types, OO is really the place you want to be. You can frequently
manage that complexity far better using OO techniques.
--
So here's the absolutely simplest example of an Object that I can think of:
a simple incremental counter, like one of those clicky things that have the
button that you press and the number displayed increases by one each time.
======================================================================
script counter
--the state - i.e. the object's internal data, stored in properties
property _theCount : 0
--
--the method(s) - i.e. the handler(s) that acts upon the object's state
on increment()
set _theCount to _theCount + 1
return _theCount
end increment
end script
tell counter
increment() --> 1
increment() --> 2
increment() --> 3
increment() --> 4, etc...
end tell
======================================================================
So far, so simple. But let's say your program needs a dozen of these
counters. No problem; you create a dozen "instances" (unique copies) of the
original counter object (the ASLG talks a bit about constructor functions;
this is probably the most commonly used way of creating multiple Objects in
AS).
Let's also say your counter needs four buttons: one to increment the count,
which we've already got; another to read the count without incrementing it;
a third to reset the count; and a forth to go put the kettle on and make
the tea. (OK, I was kidding about #4.:) But anyway, to support these extra
functions you simply add extra methods to your counter object.
Then somebody else requests that your counter also keep a list of the exact
times when it's incremented ("it'll keep the Accounts Department happy").
No problem: you add an extra property, _timesList, which contains a list,
and modify the increment() method so that it also gets 'current date' and
adds it to the end of the list. You then add a new method, getLogs(), which
returns _timesList for the pleasure and edification of those beancounters
over in Accounts, whilst also resetting the _timesList to {}.
--
Okay, so I'm not going to post the entire object at this point, but here's
how it'd look from the outside:
counter
increment()
getCount()
reset()
makeTea()
getLogs()
To use this super-powerful, do-everything counter object, all the user has
to remember is where to find it and what its methods are called (and what
they'll do when you call them, obviously). And that's it. You don't need to
know *anything* the object's internal properties or what they're doing to
use the object, and I could instantiate one of these objects, rack up a
count on it, save it to disk and send it across the channel, and you would
be able to pick it up and continue using it from where I left off; no
problem.
-------
As an additional exercise, try planning a procedural design that'll perform
all the same functions as my counter object: maintain a dozen counters at
any time, always with the option to create more, and each one allowing you
to increment, read and reset it, and view a list of the times when it was
incremented. (I'll let you off on the tea-making thing.:) You should find
yourself getting dizzy quite quickly.
-------
"OOP: less dizziness than other programming conventions."
<g>
HTH
has
p.s. If you want me to post the Uber-counter object's code, I'll be happy
to write it up for you. It's easy. Just don't ask me to design and write
the procedural equivalent as well.:p
--
http://www.barple.connectfree.co.uk/ -- The Little Page of Beta AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.