Re: Parents/Child Scripts
Re: Parents/Child Scripts
- Subject: Re: Parents/Child Scripts
- From: has <email@hidden>
- Date: Sun, 12 May 2002 12:18:06 +0100
Lachlan Deck wrote:
>
The following link has the info desired (I assume based on the question)
>
for how to call a parent's method from a child script.
[ASLG]
>
Then go to the section: Script Objects > Inheritance and Delegation.
>
>
There's a simple example in there about calling a parent method.
>
>
In short, in Java for example you'd call 'super'. In AS you use
>
'continue'...
You only need to use 'continue' when you are _explicitly_ referring to a
parent's method. This is delegation. The whole point of inheritance is that
you don't have to faff about with this sort of stuff as a general rule,
however. For example:
script parentObj
on foo()
"Hello"
end foo
end script
script childObj
property parent : parentObj
end script
tell childObj to foo()
--> "Hello"
Thanks to the use of inheritance, everyone in the whole world - not least
that tell block - believes childObj actually looks like:
script childObj
on foo()
"Hello"
end foo
end script
That tell block isn't aware that the foo() isn't really in childObj itself
- *nobody* knows this except for childObj itself. What's more, nobody else
*needs* to know.
Think of it as childObj's dirty little secret - like jotting all the
answers to a school exam on its sleeve so that it doesn't have to spend
lots of time and effort having to learn the stuff itself. (Unlike cheating
on school exams, however, this sort of behaviour is actually a Very Good
Thing in OOP and should be indulged at every opportunity.)
--
So where does delegation come in?
OK, let's say that childObj likes the general idea of having a method that
says "Hello", but being a vain sort decides that the current presentation
is a little, shall we say, "lacking"? What childObj would _really_ like to
do is have that "hello" pop up in a dialog. (Apparently somebody told it
that Graphical User Interfaces would be the Next Big Thing. And you know
how it is with kids and fashion...)
"But wait!", you cry. "That's EASY! Just change the parentObj's foo()
method to:
on foo()
display dialog "Hello"
end foo
Like, duh!"
Of course, as soon as you make the suggestion to parentObj that its foo()
method is fuddy-duddy dull and boring, you get a sharp clip around the ear
and a long lecture in why you may NOT go around telling other folks to
modify all their methods just to suit you:
"What if the parent or some other child wants to use my existing foo()? Do
you think I should change everything else I'm doing just to suit you? Just
wait till your father gets home... I can't believe you're any child of
mine... etc. etc."
So childObj decides that it's going to have its own foo() method in future,
overriding the parent's version ["Who needs parents anyway? I bet they'll
be sorry now!"]:
script parentObj
on foo()
"Hello"
end foo
end script
script childObj
property parent : parentObj
on foo()
display dialog "Hello"
end foo
end script
And for a while this might do, but it's really not that efficient: now we
have *two* "Hello"s in our script where we only needed one. And if there's
one thing we already learned when talking about inheritance, it's that
sharing somebody else's hard work is much simpler than repeating and
regurgitating it all over again.
So in the interests of *sharing* code instead of duplicating it, we use
delegation:
script parentObj
on foo()
"Hello"
end foo
end script
script childObj
property parent : parentObj
on foo()
continue foo()
display dialog result
end foo
end script
The parentObj's foo() method stays exactly as it was. Anyone who was using
it before can continue using it without fear of unexpected dialogs or other
such nonsense popping up. Meantime, the childObj continues to leech off
their parent for a few more years (at least until they go to college or get
a proper job); but that's okay really because in the world of OO this is
considered a Good Thing (i.e. borrowing is good - as long as you don't take
the family car and wrap it around a tree or anything stupid like that).
--
No doubt the class swots amongst you will realise that the childObj's foo()
is acting as a "wrapper" around the parent's foo(), enhancing the
functionality/behaviour you'll get when you send a foo() call to the child.
You might have a second child, anotherChildObj, which inherits from the
same parent but wraps its foo() in yet another way:
on foo()
continue foo()
log result
end foo
So now you've got one child that pops up a dialog, and another that writes
to the log window. Plus you've still got the parent available to use when
all you need is someone to return a simple "Hello" string.
--
Of course, the above is a really, really simple example, and you're
probably now muttering: "Pfah! All you've done is add a lot of extra lines
of code and called it 'Making Things Simpler'! What do you take me for
anyway?"
Which is true: the linecount has gone up a bit on this particular example.
But stop a minute and consider if the parentObj's foo() method was *fifty*
lines long: I'd then be saving you forty-nine lines of code, as instead of
copying and pasting those fifty into the childObj's foo() as well, I only
need to add one line to childObj's foo(): continue foo().
Plus I'm also saving you a bunch of work by making your code easier to
debug and maintain. If you should decide at some point that it'd be better
if everyone says "Bonjour" instead of "Hello". Because there's only a
single "Hello" string in the entire script, you can make this change
extremely quickly and easily (i.e. without having to muck about in your
source code with multiple find-and-replace and other slow and potentially
bug-introducing tactics).
----------
Some essay, huh? I guess it just ran and ran. Oops.
Though if anyone does actually read it, maybe you could drop me a note
telling me if I've made any sense here or if you've found useful.
(i.e. I've been wondering if I should maybe start compiling some of this
waffle into some kind of book/tutorial eventually. God knows it'd be better
than clogging up the list with transient posts.)
Cheers,
has
--
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.