defining and using globals in an application
stephen barncard
stephenREVOLUTION2 at barncard.com
Thu Jul 7 02:17:42 EDT 2011
I took a tip from Andre and basically use *one or two big global arrays* in
apps and on-rev.
- namespace problem solved. Easy to manage, remember and DELETE. I can use
the same keys for things with different arrays, name the keys anything I
want, and they can be saved to a custom property if needed. Or not.
sqb
On 6 July 2011 22:59, Jerry J <jhj at jhj.com> wrote:
> Mark,
>
> I have been bitten badly by the fact that globals persist until LC is quit.
> Actually, my injury was in the days of HyperCard, which is responsible for
> this behavior! Two stacks written by the same author which needed to run on
> the same machine - the author had habits for naming variables, including
> globals. There were so many name collisions that I gave up and rewrote the
> whole mess in LC (which was a good thing anyway). Telling the user to QUIT
> HyperCard before going to the other function didn't work out so well. Thats
> my falldown story.
>
> I have forgotten to declare globals many many times, and thats too bad for
> me. Now I turn on explicit variables for any new projects. Its a bit more
> work up front, but you find those oh-so-frequent errors and typos right
> away. And, I find I basically never need or want globals. Like Scott said,
> custom properties usually are a better idea, if a bit more verbose (which is
> not a bad thing).
>
> What language is there that will let you share variable values between
> "programs"? Controlling the scope of variable names is increasingly
> important as projects grow, and HyperCard's only mechanism, globals, wasn't
> enough.
>
> At some point you have to realize that this is the way this works. Changing
> it now would break uncountable programs. LC has given us ways to end the
> confusion. If its just the semantics of the word "global", just say NO and
> quit using it!
>
> Onward,
> Jerry "meatball doesn't work that way" Jensen
>
>
> On Jul 6, 2011, at 10:18 PM, Scott Rossi wrote:
>
> > Hi Mark:
> >
> > If I understand what you're looking for, there are other ways to get what
> > you want if you don't want to declare a global: you could use a custom
> > property or a function.
> >
> > the specialGlobalValue of this stack
> > specialGlobalValue()
> >
> > I disagree with your assessment of declaring globals as a "falldown"
> issue.
> > In fact, I would say it's the reverse. When coming back to code after a
> > hiatus of development, or when looking at someone else's code, the fact
> that
> > the global is declared as such can clarify where its value originates
> from
> > (to my mind anyway).
> >
> > Regards,
> >
> > Scott Rossi
> > Creative Director
> > Tactile Media, UX Design
> >
> >
> >
> > Recently, Mark Stuart wrote:
> >
> >> Again, my point exactly.
> >> You HAVE to declare the global again, and again where needed.
> >>
> >> I'd rather it once declared and a value put into it, the value be
> available
> >> elsewhere WITHOUT having to declare it again.
> >> It just sets up the developer for an easy "falldown". The time it takes,
> >> especially for a different developer in the same application or coming
> back
> >> some time later, to find the declared global name.
> >>
> >> Which brings up a whole new issue of intelli-sense or type-ahead
> >> variable-name-while-typing-a-script convention.
> >> But I won't go there at this time.
> >
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
--
Stephen Barncard
San Francisco Ca. USA
more about sqb <http://www.google.com/profiles/sbarncar>
More information about the use-livecode
mailing list