Jakob Hede Madsen <[EMAIL PROTECTED]> wroote
> But I'm much more in favor of starting by showing that a script -
> even an "empty" one containing only two dashes - is a magic object
> from which you can derive clones with the "new" or "rawNew" method,
> and then legitimizing these clones by showing that they can have
> separate "property-variables", and then show, that they are more than
> just proplists, because they can also have methods, that relate to
> the data they contain.
I fully agree. These days whenever I show people parent scripts for the first time,
which is almost always after they have understood the basics of behaviors, I use the
implicit (i.e. invisible) new() handler, so I don't have to explain what 'me' means,
which is difficult enough even if you don't have to explain the special case of 'me'
in explicit new() handlers.
In fact, before I even get to that point, I demonstrate how to use new() with cast
members, such as new(#bitmap) or new(#field) which is a much more tangible way of
showing instantiation because, Lo! there is the result in the cast.
Often something like;
f = new(#field)
f.text = "hello!"
After this I often show how scripts can be used as opaque containers for properties,
making more than one script with the same handler in each, but the handlers doing
different things. This plants a seed in the student's mind about how different classes
of object respond to the same command in different ways, which is connected to
inheritance and function overloading and polymorphism and all that jargon-ridden
stuff. I don't mention any of these things, but they are likely to arise, unnamed, in
the mind of the student as fantastic but improbable possibilities.
> Then after that explanation, it would be relevant to show, that there
> is a convenient way to have an "initialization" method called through
> the "new"-creator-call, without the need for an extra line with an
> explicit call to a method in the new instance.
Yes, exactly at that moment.
> I think it is more fair to the "student" to frankly say "up-front"
> that the "new" handler is not the "womb" of objects, but simply a
> convenience. In my view that would help to take some of the mystery
> and confusion out of the "mind-set", that often haunts newbies during
> their OOP paradigm-absorbtion.
I agree. The explicit new handler is too weird. I still think it's weird after having
used it for five years. Increasingly I find myself not using it even on professional
jobs, preferring some kind of custom 'init' handler instead, which also allows me to
reset the object to a default state at any time.
> But regardless: Irv it's admirable that you have made the effort and
> written a Lingo-OOP tutorial, and I'll call back when I've grown
> enough hair on my chest, to write my "Lingo-OOP the hard way"... ;-)
I have a thread running in the background with bated breath.
> And then amaze your audience by exchanging all the scriptText by two
> dashes, and do the last trick again:
>
> put script("myClass").new()
> - -- <offspring "myClass" 1 dcffb80>
Very impressive, but there's always a risk that the audience will think that this is
only good for party tricks, rather than actual work, like those sevententh century
demonstrations of Newtonian physics to the bourgeoisie. Here's a prism. It can split
light. Wow! Beautiful colors! What can I use them for? (Expecting a one line answer).
Even so, I'm convinced you have identified the gentlest path up the mountain, Jakob.
It's not as if the Newton demonstrations were about the more or less unrelated
activity of glass grinding, despite that being essential preparatory task for a basic
demonstration of optics.
> Oh, and by the way: Even "Scripts" are instances themselves, so
> beware, but that's another story.
I'm using script objects a great deal in professional work. This has been up before,
but they are extremely useful because of their scope; Less than global, but accessible
from anywhere in the movie as long as you know the name of the script member, or have
a member reference.
They are also persistent between runs of a movie in authoring, like globals, but
passed by reference, unlike globals.
They become garbage collected when you open a new movie, unless you've stored a
reference to them in a global, which is absolutely a feature, not a bug.
I use script objects as 'servers' in my larger projects. Other, typically more
transient objects will interact with them, ask them to do things and so on. For me,
they are the next step up in scope from behaviors, and so ideal when you need a
broader scope without cluttering up global namespace. Most commonly I have a single
movie script with something like;
on get what
case what of
#levelMapper : return script("levelMapper")
#levelRenderer : return script("tiler")
#player : return (sprite 5)
--...etc...
end case
end
... so I don't even hardcode the names of the scripts anywhere but this more or less
globally available central lookup table.
I have a series of 'messenger' behaviors, which evolved out of my experiences with
mTropolis. Collision Messenger, mouseUp messenger, button messenger, frameCounter
messenger, keyboard messenger and so on. You type in the message you want to send when
x happens, and choose to target the message to a sprite *or* a script, and if you
choose 'script' there's a popup menu in the parameter box where you can choose any
script member to address the message to. It's a really clean way to have data flow
from behaviors - always at risk of garbage collection - to more persistent subsystems.
'#script' of course, is a perfectly valid value for #format in the
getPropertyDescriptionList handler.
Script objects can also act as ancestors, or even common ancestors, so that more than
one object routes its unfathomed messages to the same script object. I haven't used
this technique so much because it feels a bit dirty, but I am certain it has some uses.
Script objects are therefore a good way to move from thinking in behaviors, which I
trust most people agree is step 1 up the gentle OOP lingo mountain path, to multiple
instances created with new(). You have the advantage of seeing the script in the cast,
so you know there's something tangible there, and then there's the convenience of
information hiding and all that. You could even introduce ancestors before new() using
only friendlier objects like scripts and lists.
-Brennan
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
