Fwd: OO Theory misconceptions (was Re: can I make a list of records? (OO Theory Hell))
Fwd: OO Theory misconceptions (was Re: can I make a list of records? (OO Theory Hell))
- Subject: Fwd: OO Theory misconceptions (was Re: can I make a list of records? (OO Theory Hell))
- From: email@hidden (Michael Sullivan)
- Date: Wed, 30 Jan 2002 16:52:01 -0500
- Organization: Society for the Incurably Pompous
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:
>
[Scene One]
>
Object A : "I am an object, bustling around cleaning house as I do.
>
Tra-la-la-la-la!"
>
[Knock at door; from outside a voice shouts]
>
Object B : "Hi there! I'm an object of the wild partying sort. We
>
should get together and boogie!"
>
[Object A thinks "Omigod, I look such a sight in these dirty old overalls!"]
>
Object A : "Sure thing! Just hang on a moment and I'll be right with
>
you..."
>
[Object A changes out of its workaday clothes and into its best party duds,
>
then opens door]
>
Object A : "Okaaay! Let's get it ON-N-N, baby!"
>
Object B : "Rockin'!"
>
[Objects A and B get together, party all night as the perfect couple and
>
live happily ever after...[1]]
>
>
At least I think that's how it works... I haven't been on a date
>
for...<COUGH!> I mean, I haven't been learning OO theory long and my brain
>
is still numb from trying.
>
Another example would be:
>
>
get 3 & 5
>
--> {3, 5}
>
where 3 sees 5 coming from a mile off and, knowing that numbers can't
>
concatenate for sh*t, decides to make like it's a list {3} instead (since
>
it knows that lists can).
>
>
>
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.
So you have to go to apps for this behavior.
Polymorphism happens when you have complex objects which inherit
properties from other classes of objects.
The classic example is where you represent shapes as objects. A program
may have an object class called "circle" and another class called
"Triangle" and yet another class called "Rectangle". Now there may be
yet a fourth class called "Shape" by which you can address certain
methods of any of these objects.
And command that operates on a "Shape" should be able to be operate on
any of the other objects I've described. And so, in a good OO design,
"Circle", "Triangle" and "Rectangle" would all inherit a number of
properties and functions of "Shape". A command/handler/function/method
that expected a "shape" could be passed an object of any class which
inherited from "shape", such as a "circle" or a "rectangle" and it would
treat it appropriately.
Real polymorphism happens when certain commands/methods in the "Shape"
class, get treated specially depending on what kind of "shape" is
accessed.
So, Circle, Rectangle and Triangle may have different ways to perform
the "Redraw" method in Shape's dictionary entry, but when you call
redraw aCircle
it calls circle's specific code for redrawing itself, not some generic
function in shape.
<hairy programming implementation details>
In implementation (in C++ at least, the only reasonably OO language I'm
all that familiar with, bear with me if you use other vocabulary for
this stuff), shape won't have any actual code in its redraw method, just
a header definition of what kind of arguments it takes and returns and
an indication that it is a virtual function. Then every class that
inherits from "Shape" must define the actual function. The function
dispatch then happens at run time rather than at compile time.
Languages that are more wholeheartedly OO, I think do all function
dispatch at run-time (small performance cost even when not using
polymorphism), and may not require this kind of distinction in class
design.
</hairy programming implementation details>
To use a good concrete example that I script every day, if you know
Xpress, consider boxes.
You can have text boxes, line boxes or picture boxes. All of these are
also generic boxes, and may be accessed by certain commands that work on
generic boxes. If you call a command that works on generic boxes, it
will work no matter what kind of box you pass it, and if it should work
slightly different depending on what specific kind of box you pass, it
will. That's polymorphism.
Now Xpress, if my info is correct is all written in plain C, so they've
obviously implented this in some other way than I described above
(probably storing function pointers as part of the object's structure
and using void pointers as arguments, etc.) Not exactly sure, I haven't
applied for my Xpress SDK yet, but the behavior is (for objects without
bugs) what you'd expect from a good OO program, so they've clearly tried
to do OO-based design even though they aren't really in an OO language.
Anyay, I hope this has helped more than hurt.
I'm not any kind of OO expert, and there's probably a couple of real
programmers on this list shaking their heads at some of this. I'd guess
there are some other newsgroups or mailing lists that would be more
helpful for discussing OO theory.
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.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden