At 11:28 +1100 2001_12_05, Luke Wigley wrote: >What makes an object different from an uninstantiated script is that objects >are 'active' - in the sense that they exist in memory and are able to store >data (in their 'properties'). This is what makes objects more powerful than >uninstantiated scripts.
Even scripts are actually sort of "instances" themselves, and does everything regular instances does, including holding properties and existing outside the scope of their "parent-member". I'll try to explain a bit, but when you start to refer to scripts as "instances themselves", the terminology becomes quite awkward, I guess there would be real OOP terminology for this... but for now, please bear with me. Given a script with only this line: property p Try this in the message window: m = member "myClass" o = m.script o.p = #x m.erase() put o.p -- #X Instead of "erase" you could also just leave the current movie, and the results would be the same. You could even then go back to the movie, and create a new "instance" of the script, and fill it with a new value, and the two "instances" would happily and separately coexist. When you create a scriptInstance in Director, you get a reference to the "object". The object lives in RAM allocated for it, but while each object does point to its own private memory allocation for properties, all scriptInstances of the same "script" points to a common memory address where they share the same code-base. That shared code-base is actually an "instance" of the script itself, and that is why the instantiated objects can live past the scope of the parent-member; The script itself is instantiated into RAM, so that the objects can access their common code-base. You can also provoke a new "instance" of the script by altering its scriptText, and new "objects" created from the altered script, would point to a new "instance" of the script. When you coerce a scriptInstanceReference to a string, by putting it to the messageWindow, you get a clear indication that it points to a private memory-allocation, because it reveals a unique number: -- <offspring "myClass" 1 dcfb7a0> When you do the same with "just a script", it isn't as apparent: (script "myClass") And that confusingly hides the fact, that the script-reference actually points to an "instantiated" memory-allocation. So how does the "script-instance" survive garbage-collection, when there's no explicit reference you may ask? Probably just because on a lower level... but even if the speculation is academic, you *can* access the "script-instance" reference, through any of the derived objects, by their "script" property, and that alone explains what keeps the "script-instance" refCount up. 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!]
