At 23:01 +0100 2001_12_05, Brennan wrote:
> > 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.
I use them for very much the same purposes you described,
particularly because of their scope.
But still, that's not my point by calling them 'instances'.
I am afraid that I am only causing confusion by using that word -
'instance', which in Lingo is mostly tied into meaning actual
'scriptInstances', ie: it's synonymous with the concept of 'object'.
Many things in Director are 'objects' without also being 'instances':
A memberReference is an 'object' but it points directly to the
member-slot and not indirectly to the current instance of the member,
ie: if you change the member and make a new reference to it, both
references will point to the very same object or 'memory-zone'.
And this is where 'script' differ.
If you make a reference to a script, and then alter and recompile the
script, and make a new reference, the two references will actually
point to different addresses, even if - by string representation -
they appear to point to same scriptMember.
Does this have any real world implications?
Yes.
I remember when starting my own foray into Lingo-OOP, I would often
be confused when debugging, because the alterations I did to the
scriptText apparently didn't influence the objects. This was of
course because I made a blunder, and actually still worked with
scriptInstances created prior to the recompile. I was using the
actorList to more good than I could handle, and didn't get it cleared
properly, so I had old ghosts hanging around and behaving stubbornly.
Of course, you don't need to know this "scripts are instances" in
order to operate out of such mistakes, you just need to know that
objects behave like 'snapshots' of the code at a given moment.
But how do the objects do that, "I still obey my old master as he
was, even if you changed him"?
They do so, because their 'script' property still points to an
'instance' of the scriptMember, as it was compiled at the time of
instantiation of the script into a 'child-object.
And when you change the script and recompile it, a "new" "instance"
of the scriptMember is created and used as the basis for further
scriptInstances.
It would also have runtime implications if you used dynamic
scriptText, but that's obviously so geeky as to have weird
implications anyway... ;-)
But maybe a more likely runtime-implication is if you use
scriptObjects referenced globally, perhaps indirectly globally
referenced by other objects otherwise globally referenced. You then
branch to another movie and back again, and then create some new
object, which in turn grabs itself a reference to the script-object,
but by name, and *then* you expect the "early" and the "late" objects
to point to the same script-object... but they wont.
OK, here's a testbed example where objects apparently know all their
siblings through a common list, stored in a property of a
scriptObject, in fact in their own parentScript. Somewhat akin to a
'static' variable in C++ AFAIR.
It is meant to illustrate a potential runtime-implication of the fact
that scripts are "instances" of scriptMembers:
It assumes that the code is implemented in a movie named "a", and
that another dummyMovie named "b" is availabe.
----<movie script: (member 2 of castLib 1)>----
global gObjectList
on hTest
script("myClass").pInstanceList = VOID
gObjectList = []
hCreateObject()
hCreateObject()
put #first_round
call #mTest, gObjectList
put #movie_branch
go movie "b"
go movie "a"
hCreateObject()
hCreateObject()
put #second_round
call #mTest, gObjectList
gObjectList = []
end
on hCreateObject
gObjectList.append(script("myClass").new())
end
----</movie script: (member 2 of castLib 1)>----
----<parent script: myClass>----
property pClass
property pInstanceList
on new me
pClass = me.script
pClass.mAppendInstance(me)
return me
end
on mAppendInstance me, aObj
if pInstanceList.voidP then pInstanceList = []
pInstanceList.append(aObj)
end
on mTest me
put #mTest, pClass, pClass.pInstanceList
end
----</parent script: myClass>----
-- Welcome to Director --
hTest
-- #first_round
-- #mTest (script "myClass") [<offspring "myClass" 4 eaaad48>,
<offspring "myClass" 2 ea3eba0>]
-- #mTest (script "myClass") [<offspring "myClass" 2 eaaad48>,
<offspring "myClass" 4 ea3eba0>]
-- #movie_branch
-- #second_round
-- #mTest (script "") [<offspring "" 4 eaaad48>, <offspring "" 2 ea3eba0>]
-- #mTest (script "") [<offspring "" 2 eaaad48>, <offspring "" 4 ea3eba0>]
-- #mTest (script "myClass") [<offspring "myClass" 4 e3ac514>,
<offspring "myClass" 2 e3acbcc>]
-- #mTest (script "myClass") [<offspring "myClass" 2 e3ac514>,
<offspring "myClass" 4 e3acbcc>]
So even though all the objects should apparently point to the same
common repository scriptObject, they have become separated into two
different "instances" of the parentScriptMember.
(Which is why I said "beware" in the first place... ;-)
Notice also the "empty" name of the first script and its instances.
(You _can_ still have different scriptMemberInstances without this
obvious give-away, but it is apparently a consequence of the
movie-branching.)
Ok, 'nuff instances of that word, it's getting worn quickly.
Hope it makes sense (soon)... ;-)
Jakob
[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!]
