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: email@hidden
- Date: Thu, 31 Jan 2002 00:02:31 -0500
On Wed, 30 Jan 2002 16:52:01 -0500, email@hidden (Michael Sullivan) of the
Society for the Incurably Pompous wrote,
has writes:
>
There's a feature of OO languages called "polymorphism" - literally
>
translated as "many forms". An object can take any of several forms as
>
needed. This lets another object (the needy one) to interact with it more
>
easily, and without having to ask it all sorts of embarrassing personal
>
questions first.
>
For example:
>
[...]
>
At least, I HOPE I've got all that right. But it explains why {} can behave
>
in more than one different way, according to circumstances. [2]
>
>
This isn't really polymorphism but simply coercion.
>
>
I don't think there's any polymorphism inherent in the raw AS language,
>
and I'm not sure you can even implement it with user defined objects and
>
handlers within AppleScript (go ahead Arthur, make my day). Applescript
>
and apple events do understand and let you take advantage of
>
polymorphism in an app's class definitions.
Because AppleScript is a dynamically-typed language, you get polymorphism
essentially for free. Another way of viewing it is that you have to *worry*
about being polymorphic, because there is no type checking for handlers.
Here's a quick example of a silly polymorphic handler:
on double(x)
if class of x is in {integer, real} than return 2*x
if class of x is string then return x & x
return "Make mine a double!"
end double
The handler 'double' is polymorphic because it does different things depending
on what you give it.
AppleScript also can do polymorphism in a very useful way through the
inheritance rules for script objects. Here's slight variation on the silly
handler above, a class of silly objects that each can double themselves and
display themselves. The numeric object can also find its own square root, but a
string silly object can't.
on makeSillyObject from initialValue
script
property v : initialValue
to display()
display dialog "The silly value is " & v
end display
to double()
return "Make mine a double"
end double
end script
end makeSillyObject
on makeSillyString from initialValue
script
property parent : makeSillyObject from initialValue
to double()
return my v & my v
end double
end script
end makeSillyString
on makeSillyNumber from initialValue
script
property parent : makeSillyObject from initialValue
to double()
return 2 * my v
end double
to root()
return sqrt(my v)
end root
end script
end makeSillyNumber
makeSillyObject from {4,2} returning sO
makeSillyString from "Hi" returning sS
makeSillyNumber from 37 returning sN
tell sO to display()
tell sS to display()
tell sN to display()
{double() of sO, double() of sS, double() of sN, root() of sN}
--> Result: {"Make mine a double!", "HiHi", 84, 6.480740698408}
[ Shapes example deleted ]
>
I actually think worrying about OO hurts more than helps for the typical
>
applescripter. You have to get the idea of how an object hierarchy
>
works, but there are a lot of very hairy implementation details in doing
>
an app's OO design and making all the appropriate behavior happen that a
>
client scripter shouldn't ever have to worry about, though might
>
occasionally when dealing with buggy or poorly designed apps.
Using objects is really pretty natural. "Tell [object] to [action]".
"[property] of [object]" The objects encapsulate data and functionality in a
very natural way. That's the fundamental reason for using object-oriented
design methods. (Not because you like saying "polymorphic" and "nonvirtual
overriding" :-b )
There are some annoying syntactical details of defining objects within
AppleScript, though. Like in my example above, the "Constructor" approach to
creating an object is pretty counterintuitive. If you don't read the
AppleScript Language Guide, you'd never dream up the idea of stating an unnamed
script object and having that returned as the value of the function. And
chaining the parent and child together through a dynamically-generated 'parent'
property is also highly non-obvious. You can do things more simply with a
static definition:
script someSillyObject
to display()
display dialog "The silly value is " & v
end display
to double()
return "Make mine a double"
end double
end script
script someSillyString
property parent : someSillyObject
property v : "Hi"
to double()
return my v & my v
end double
end script
-- etc.
But now you only get one of each object, and each child has to provide the place
for the property v, even though all children will use it. (You could put v in
the parent, but then you'd have to have initialization code in the parent and
through all the children to set up the initial value at run time.)
So, while the "constructor function" approach is oddly inside-out, its what I
use all the time. I usually won't go to the trouble of defining an object and
then only making one of it--its like defining a function and then only calling
it once.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden