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: Thu, 31 Jan 2002 22:42:02 +0000
The scores so far:
has gets a C+ for trying, even if he did get it arse over tit (whass new?),
Michael initially received a B- for flubbing it at first -now revised to B+
thanks to nice recovery, and Scott gets beaten up in the playground for
being Class Swot - Again.
;) Now, on with the show...
Michael Sullivan wrote:
>
> 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.
The class+method approach to OO implementation appears to be the most
familiar one (from what I've seen on my travels), but certainly isn't the
only one. I think AS's client-side implementation is perhaps closer in
concept to something like SELF, which uses the concept of "prototypes"
instead (pre-built objects which can be cloned as required). Executing AS
code containing a 'script' block seems to instantly create a living,
breathing object out of nothingness. Whereas classes seem more like
predefined templates; simply a pre-existing pattern that you use to stamp
out new objects, cookie-cutter style. [Anyone want to tell me if that's a
good and accurate analogy or not?]
However, I think one of AppleScript's unofficial mottos is "using two
different approaches to every problem";), with app-side OO seeming to be
done on the class model, and user-side OO feeling more like prototype-based
OO.
And, continuing with the "two ways" theme: with user-side objects, you can
EITHER use constructor functions to roll new objects OR "copy" to clone
existing ones. Incidentally, both those methods seem to show different
behaviours WRT inherited parent objects. If you use a constructor function,
the child objects all share a single parent. However, if you use 'copy',
the child ends up with its _own_ copy of the parent. [My own experience
suggests this, though perhaps Scott could confirm this/correct me.]
BTW, for those who want to be really cute:
script someObject
on cloneSelf()
copy me to x
return x
end cloneSelf
--
end script
tell someObject to cloneSelf()
--> a copy of someObject
Handy if you're looking for somewhere to put that 'copy' call.
>
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.
You weren't the only one - it took me about a dozen readings of that ASLG
chapter to a. see the point of OO, and b. understand how to use it. It
doesn't make a good introduction, unfortunately.
>
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.
Scott's Silly example was pretty wild by anyone's standards, and certainly
not the only approach (or even a common one). You'd probably more commonly
use:
script parentObj
--some stuff
end script
on newChild()
script
property parent : parentObj
--more stuff
end script
end newChild
in which case there's only a single 'instance' of parentObj that gets
shared by all the child objects.
>
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
It's not ideal, but I guess that as long as clients keep to the published
interface it shouldn't be an issue (yes? no?). I'm getting into the habit
of using a simple naming scheme to distinguish between public and private
and reduce the chance of accidents/confusion, as in using: publicHandler(),
_privateHandler().
>
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 don't think AS is a solution if you need _real_ security. (As you say,
obfuscated != secure.)
>
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.
I'm still looking for a really easy-to-read OO book (i.e. under a half-inch
thick, with simple words and lots of pictures). The three-inch tomes I have
looked at in the bookstores I simply can't hack; it's really hard trying to
grok code examples in C++/Java if you don't know those already, and they're
pretty much overkill for learning/using OO under AS anyway.
OOP definitely has a place in the AS world. I just wish there was a good,
clear book on the subject that was geared towards ASers. (So, Scott - you
wanna write one?)
Cheers,
has