Re: Audience for globals discussion?

[Matthew Wild <mwild1@...>]

On 18 August 2010 13:04, Patrick McCavery <patrick@cakeandfile.com> wrote:
> Thanks Rob, thanks Steve
>
> Could I get a "ballpark" number on pollution? 10's, 100's, 1000's ?
>

No, there is no ballpark figure. The more globals you have, the harder
it gets. There's no place where having a certain number of globals is
fine, and adding one more global suddenly makes your application
unmaintainable :)

Not using globals is a design principle, modules should be
self-contained, and not depend on external state, and not expose their
internal state to other modules. Keeping code self-contained makes
sure that when something goes wrong you know there is only a certain
amount of code that can be changing a given variable, and you don't
have to hunt through the whole application. It also means you can
safely replace the module's internals, so long as you keep the
external interface the same. There are numerous other advantages.

There is no excuse for always using globals for data sharing in an
application. I'm not saying they should never be used, but they should
only be used when you can't use a local, or when data you want public
can't be exposed by some other method.

Quick short scripts, yes, I'll often use globals - it's not related to
there being few of them, but that generally such a script is just a
single file. However even this is bad in practice, because these short
scripts always tend to grow sooner or later, then you regret it :)

> When we speak of registers are we talking about the CPU's registers? Lua is
> quite abstracted from ASM, isn't it fairly hard to tell which variables
> actually end up in the registers even with C?
>

No, Lua VM registers.

> Is the 250 limit based on Intel X86 architecture? A large local table still
> won't fit into the registers, no? Won't we still have to access it from ram
> or disk?
>

No, it's not.

Matthew