script local variable

[mister]

i thought i understood script locals, but maybe not. I have a field with 3 buttons on one card. i'm trying to make a list( local) from a master list(global). the problems is with the "choose button", it doesn't populate the "test field". it works fine if i use a global variable instead of script local.
The answer sList shows data in the variable. the global and local declarations are at the top of both and spelled correctly.

global gList
local sList

"button pick"

Code: Select all

on mouseUp
   repeat with x = 1 to the number of lines in fld "test"
      if the hilitedline of fld "test" is x then
         set the foregroundColor of line x in fld "test" to 0, 0, 200
      put line x of fld "test" & cr after sList
      end if
   end repeat
  answer sList
end mouseUp

"button choose"

Code: Select all

on mouseDown
   put empty into fld "test" 
end mouseDown

Code: Select all

on mouseUp
   put sList into fld "test" 
end mouseUp

Larry

[FourthWorld]

A script-local variable is available to all handlers within a given script. To use a variable across different scripts you would need to declare it as global in each script that uses it.

[Klaus]

Hi Larry,

"scriptlocal" means local in ONE script***, but you have 2 different scripts!
So in this example you better use a global variable.

***Like this:

Code: Select all

local senseless_var

on opencard
  put the seconds into senseless_var
end opencard

command show_ senseless_var
   anser senseless_var
end show_ senseless_var

on closecard
   put empty into senseless_var
end closecard

You get the picture


Best

Klaus

[mister]

Klaus & Richard

I've been in a hurry to get this app finished and i've been rushing to fix things without thinking. i guess i started associating "script local" with cards. There's my card and my buttons are handlers on that card and those buttons that are affecting the field on that one card, so it must be local and why isn't it working. i get it again. Thanks for setting me back on track, both of you.

Larry

[MaxV]

It is well known that global variables are generally a bad thing.
Don't use local or global variables, but custom properties. Read here: http://tinyurl.com/oshbkc9

[FourthWorld]

What is well known is that most programming languages support global variables, not because so many computer scientists are all wrong but because sometimes globals can be quite useful. Like any language feature, including custom properties or anything else, it's possible to use them in contexts that they're not optimal for. But when they're a good option there's no reason not to take advantage of this nearly-universal feature of programming languages.

Read here:
http://forums.livecode.com/viewtopic.ph ... 57#p129457

[dunbarx]

What Richard said.

Custom properties are wonderful, powerful and ubiquitous. They are accessible across stacks:

Code: Select all

answer the xyz of stack "someOtherStack"

whereas global variables are only available within the stack where they live, and within scripts where they are declared. Nonetheless, globals have gotten a bad reputation over the years. Whether this stems from the days where memory was an issue, or whether they were accused of causing all sorts of clutter is unimportant. They are a tool; use them wisely. Or not.

Craig Newman

[FourthWorld]

...whereas global variables are only available within the stack where they live, and within scripts where they are declared.

To clarify, while globals do need to be declared in each script that uses them, any script anywhere in the current LiveCode process can access them, not just within the stack where they originated. Maybe a typo where "within the stack where they live" could be "within the script where they live"?

Nonetheless, globals have gotten a bad reputation over the years. Whether this stems from the days where memory was an issue, or whether they were accused of causing all sorts of clutter is unimportant.

Memory is a minor concern, since globals can be cleared even more easily than a custom property. And because a custom property requires an object to be bound to, using a prop carries the additional overhead of a few bytes for the object to store it in, and an extra pointer to link its RAM location to the object structure. Small stuff, though, with no practical impact.

The bigger issue with globals is about code management: being globally writable by design, we need to be mindful when we write to them. Of course each of the alternatives also comes with their own trade-offs to be mindful of, so as with the rest of life we find programming offers no single magic-pony solution for all possible use-cases. Any team disciplined enough to make good use of one option can probably also make good use of any other.

The article Oliver Kenyon wrote more half a decade ago that Max linked to offers some useful guidance about the potential misuse of globals in software architecture.

As helpful as much of that article is for many of its technical explanations of our options, I'm fairly confident that if Oliver were writing it today he'd offer those with a less strident tone. After all, at the time Oliver had worked on the IDE team at LiveCode, and used globals extensively himself. This may be why no one currently on the core dev team has ever written any such a sweepingly prohibitive recommendation. Ah, the certainty of youth.

Like my old English teacher used to jokingly tell us, "Never use absolutes."

[dunbarx]

Richard.

Brain typo. Of course globals are, er, global across stacks.

Craig

[rinzwind]

Performance wise locals and globals are preferable to properties. Especially when one accesses or changes them many many times in loops etc. It would be nice if ther was something like a stack scope variable or card scope. But nope. Its all or nothing right now. Array handling trough properties especially incurses a major overhead. A possibility for a by ref return value would be a fix for many performance related coding problems (instead of copying, changing, cooying back). The new by ref until write helps. But still.. a language construct to return a memory reference to a var would be nice. Linked list would become possible too that way.