> In it, we make extensive use of global name space objects [..].
> Within each object, all state is represented within the properties of
> the object itself.
Why bother with namespaces, if not because you recognize that it's a bad
idea it is to dump everything in the global namespace? Any measure you
take to limit the scope of variables (be it to a block, function,
class, namespace, etc.) -- as you have done -- is proving the point.
> Globals do not necessarily impede modularization and encapsulation
Of course they do, by definition! Code that stores it's state outside
itself, where anybody can stomp on it, is NOT encapsulated. When some
other code writes to the same global(s) and your code breaks, you CAN'T
debug the problem by looking at *your* code, the unit tests for *your*
code are worthless, you need to look at the entire code base -- because
your code was not encapsulated.
Code with global state is harder to understand, test, maintain, and
debug. It is a core principle of good software architecture that you
limit coupling, limit the visibility (i.e. scope) of objects as much as
possible.
See: "Global Variables Considered Harmful", Wulf and Shaw, 1973.
> If you happen to need a temp variable for a particular task, you
> create a property of the object itself to hold it.
Why? If a local would do, why would you deliberately broaden the scope
of a variable's visibility (and vulnerability) unless you had to? This
is an especially decision in Lua, where locals give you better performance.
