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 (Michael Sullivan)
- Date: Thu, 31 Jan 2002 13:42:16 -0500
- Organization: Society for the Incurably Pompous
Scott Norton writes:
>
On Wed, 30 Jan 2002 16:52:01 -0500, email@hidden (Michael Sullivan) of
>
the Society for the Incurably Pompous wrote,
>
> 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
Yeah, you're right -- in the broadest sense polymorphism is just the
ability to do different things based on the type of an object. Although
I think of it the way it's conceived in C++ or Java which is downcasting
only.
Of course you can code polymorphism in the broadest sense into any
non-nazi typed language with casts and structures with type flags. But
I guess the mere fact that applescript gives a "class of" raw command
and stores that data automatically in every object would give it some
claim to object orientation over a language like C.
>
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.
[good code example snipped]
>
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 )
Yes, I was trying to claim that AS is client (user) side object
oriented, but that the actual implementation of true OO had to be in the
class programming outside AS. Until I saw your example. It does appear
to work pretty much as I'd expect inheritance to work.
[more snips]
>
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.
Oddly, I think it may be the more traditional approach to objects that's
inside out. I've gotten sufficiently used to it that the idea of
encapsulating the object in a constructor handler took a few minutes to
grok, but I actually think that might have been easier when I first
learned about OO.
There are two other things that I don't like a lot more.
One is the fact that every user object in AS is a "script". I have to
get used to thinking of "'script' == 'class'", because that's totally
counterintuitive to me. I think this is what got me so confused the
first time I went through the ASLG that I bagged any idea of trying to
create my own script objects until I started reading about tricks on
this and the macscrpt lists -- but until now I never quite grokked the
equivalent of a script in AS to a class in other OO languages.
The second thing I don't like is the inclusion of a whole parent object
as member data of the script object. That strikes me as very
counterintuitive. It's basically encapsulation rather than inheritance,
but because of the way AS typing works one can make it behave like
inheritance.
The fact that all data is public is a bit of a drawback as well.
(Although I suppose if you distributed a Run Only App as a library, you
could put your own dictionary in hiding implementation details and thus
keep client scripts from using properties you don't want them to. S
eems like more work than it's worth for most things, though -- and a
client scripter could still get to the private members if they knew the
raw AE codes.
I guess a determined (and probably foolish) C++ client programmer can
also bypass privacy with raw pointers and casting if they know the
memory layout of a library class.
In any case, I must thank you, Scott! It is you who have made my day
today (Sorry, Arthur, I am sure your time will come again).
You've made me realize I really *can* create objects with applescript.
I need to go back and read the ASLG again. Part of my problem may be
that I hadn't done any OO programming when I first read the ASLG a
couple years ago and all the script object stuff just went right over my
head. Since then I've learned and played with C++ and Java a bit, plus
read some excellent books on object and programming theory, and OO
construction is starting to make more sense to me.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden