Re: OO Theory misconceptions (was Re: can I make a list of
Re: OO Theory misconceptions (was Re: can I make a list of
- Subject: Re: OO Theory misconceptions (was Re: can I make a list of
- From: has <email@hidden>
- Date: Sat, 2 Feb 2002 13:18:01 +0000
Jason W. Bruce wrote:
>
> Where on load script, a handler called initialise() is called, which does
>
> some setup and creation-time stuff (in this case, setting a birthday
>
> property).
>
>
>
I think this feature is present in the language. If you load a script as a
>
parent to the current script, the loaded script's implicit run handler will
>
execute:
>
>
property parent: load script file.lib
Not so - "load script" merely returns a specified script object; it does
not invoke its run handler. Maybe you're getting confused with the
operation of AS's inheritance scheme: where if your child script has no run
handler of its own (either implicit or explicit) then it will call its
parent's run handler (if any) at runtime.
--
>
but to me the
>
real value of OO in AppleScript is that it's simply a way of breaking down a
>
complex script into manageable parts.
This isn't OO in itself - it's structured design. Modularity is a
concept/feature that OO languages copied from the structured languages that
preceded them. (Or to paraphrase: good languages borrow, great ones steal.:)
You can take advantage of AS's OO foundations even when writing purely
procedural code. One of the nice things about AS is it's very flexible,
allowing you to use either procedural or OO programming techniques however
you see fit. AS provides scripters with a high level of "home comforts", if
you like.
>
So the next level of
>
organization is to break these handlers into groups and put them into script
>
objects.
There's nothing inherently OO in spreading your code across multiple files
to make it easier to manage. You can do the same in C (a non-OO language),
for example; the compiler simply pulls everything together at compile time.
>
For example, if you have a script which collects data from a FileMaker Pro
>
database, creates a Quark document with that information, sends an email
>
notification, and then checks as completed a task in the Palm Desktop, you
>
can create in your script a script object named filemaker which has all your
>
handlers targeted to FileMaker Pro, a script object named Quark which has
>
all your handlers targeted towards Quark Xpress, a script object named OE
>
which has all your handlers targeted towards Outlook Express, and a script
>
object named Palm which has all your handlers targeted towards the Palm
>
Desktop. Instead of calling a series of handlers, you now call filemaker,
>
Quark, OE, and Palm.
Descriptive variable/handler/script names are certainly a good way to make
code easier to read - especially six or twelve months later once you've
forgotten the details of how it works. (By comparison, simply naming stuff
x/y/z or theString/theNumber isn't nearly as informative.)
BTW, here's an example of an OO feature used in service of non-OO programming:
script
property parent : application "Finder"
on deleteFile(fileRef)
delete fileRef
end deleteFile
end script
This takes advantage of AS's inheritance mechanism to inherit stuff from
the Finder (e.g. its 'delete' call), but there is nothing OO about the
deleteFile() handler. So this is still essentially procedural programming,
made easier by using one of AS's OO behaviours to avoid the need for
separate 'tell application...' blocks.
>
When you want to add a handler or feature sixth months or a year later,
>
you've created a clean organizational structure so you know right were to go
>
to add the feature -- and adding it doesn't affect any of the other portions
>
of the script outside of the script object. Inheritance and instances and
>
constructor functions are great. But in the end, it's the modularity of OO
>
that is in my opinion the real advantage.
Well, what you have there is good-quality structured programming - you
might be exploiting some of the language's OO underpinnings in the process,
but your design is still procedural. It serves well for many tasks and
helps keep your code easy to maintain in future; and in many respects
readability and maintainability have much more significance than which
programming style has been used.
HTH,
has