Parent of Target

[Bob Sneidar]

Remember that arrays stored as properties provides a kind of scoping. For example 2 stacks can hold the same array but with different values in a property with the same name. The added advantage is they are persistent through idle and you can now check the contents of the properties by drilling down in the property inspector to the value you want to check to see what it contains. 

Properties work great as a kind of scoped global. 

Bob S


> On Aug 9, 2017, at 18:24 , Sannyasin Brahmanathaswami via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Addendum on Scoping
> 
> This new "modular" world, of behaviors, libs that have been put into msg path with "start Using" or "insert into back".. text files, multiple binary.livecode stacks -- not substacks as such, but separate.livecode files.
> The app is now a complete "environment/framework". With Andre constant warnings along with my experience using globals in this environment gets very dangerous very fast, typically want to use an array to starts holding all kind of things we think we need to reference across many different stacks/libs. Seems OK on the surface, but then as Andre says, if  someGlobalArray["fruit"]  = "apple" when you thought for sure it should now be "orange" then then debugging "hell" door opens. So instead we start sending and dispatching commands, setting up locals in scripts with lots of small 
> 
> local sCurrentFlavorA
> 
> function returnCurrentFlavor
>   put sCurrentFlavorA["fruit"]
> end  returnCurrentFlavor
> 
> So now, with debug on you can trace easily where things are happening.  so some way to track, not only "where did this come from" (which is what debug stepping is really doing) but to look "up"   "Who is asking?"  
> would be interesting.