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.
> On Aug 9, 2017, at 18:24 , Sannyasin Brahmanathaswami via use-livecode
> <email@example.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
> 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.
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription