At 18:26 +0100 2001_12_05, Daniel Devolder wrote: >>Jakob Hede Madsen wrote >> >>> Oh, and by the way: Even "Scripts" are instances themselves, so >> > beware, but that's another story. > >put script "parent" >-- (script "parent") >put new (script "parent") >-- <offspring "parent" 1 13504630> > >We have two different things here.
Yes we do: Scripts and scriptInstances. Or classes and objects. But even the class is an object, and not only that, it is actually an instance of the sourceCode. >The script value is the owner of the Lingo bytecode. > >The instance/offspring stores the properties and their values, and >also a pointer to the parent script, but not the actual bytecode >which is stored with the parent #script object > >So #script and #instance are two different things. Yes, and this is why I said that the terminology would be confusing, because I use the term "instance" in a broader sense than just actual scriptInstances, when I refer to scripts as "instances" themselves. Probably scripts and scriptInstances share the same "codeObject" superclass, but scripts have an xtra layer containing the "new" and "rawNew" methods for creating new scriptInstances. I've been thinking about this terminology confusion, and maybe it would help to establish three different "layers": 1) the scriptMember containing the scriptText 2) the script 3) the derived scriptInstances My main point when arguing that scripts are "instances" is that they are instances of the scriptMember - they are not the scriptmember, and if you store a reference to a "script" and then alter and recompile the scriptMember, you will see that the "script" is in fact now a new "instance" of the scriptMember, and that these two instances are separate entities, even if they're spawned from the same member. So we have: 1) scriptMemberObjects 2) scriptMemberInstances: scripts 2) scriptInstances: scriptInstances >But you are right as you can use the two the same way. For example >you can change the content of the properties of a parent script like >you do with a child instance: According to the idea of them sharing the same "codeObject" superclass. >This means that in fact the #script object is a pointer to a memory >zone with space not only for the bytecode of the Lingo script *but* >also for the properties and their values. Yes also that, even if it isn't central to the concept of scriptInstances sharing an indirect reference to the same memoryZone of byteCode. >So it is in that sense that is right to say that #script objects are >#instance objects themselves, because you can use them the same way. You can use them the same way, and that has been one of my other points, but it is not my point by calling scripts "instances". >But you could also say the reverse: #instance objects are the same >than #script objects, the only difference been that the bytecode is >stored with the #script and the #instance objects don't duplicate >it, keeping only a pointer to the parent #script. Good point, and on top of that scripts are "fertile" and objects are not. Daniel, it's nice to have you playing along with this rather abstract discussion, but I think you missed my point, when I said "even scripts are instances"... did you get a clearer picture now? Of course everything I've said in this thread is more based on my own empirical deductions than actual information from those who made the abstraction we know as Director, and I suppose you've actually read more about the innards of Director, given that you've created an Xtra... so do you agree? Regards, 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!]
