gcanyon at gmail.com
Thu Aug 8 22:15:40 CEST 2013
Dang, that's right, and I completely borked what I said -- local variables
are unique to the object, not the scriptObject. So yes,
scriptObject local MyVar
or something like it would make sense for this use case.
On Thu, Aug 8, 2013 at 3:06 PM, Richard Gaskin
<ambassador at fourthworld.com>wrote:
> Geoff Canyon wrote:
> On Thu, Aug 8, 2013 at 8:01 AM, Timothy Bleiler wrote:
>> So, to the extent that it might effect preferences for the syntax, what
>>> are some examples of how this would be used?
>> This seems similar to the distinction between class and instance methods.
>> Class methods are often used to store values that all the instances share
>> in common. In LC, a local variable in the behavior seems like the
>> reasonable way to handle this. For example, if you are writing Space
>> Invaders and need to keep track of how many invaders are left, a local in
>> the behavior script for the invaders would work.
>> Having the scriptObject would let you store properties on the behavior
>> object, which might come in handy if you want to save the stack? Not sure.
> This raises an interesting question: What if you don't want to save those
> values? Or what if the value you want to use is a nested array, which is
> much slower to get in and out of a property than it is from a variable?
> Once we start down this road, we should consider a directive for variable
> declarations to be used by the class rather than the instance, perhaps
> something like:
> scriptObject local MyVar
> local to scriptObject myVar
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> Follow me on Twitter: http://twitter.com/**FourthWorldSys<http://twitter.com/FourthWorldSys>
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode