[AccessD] Class Rebuttal was: Basic Unbound Form ...

"It's poor design that makes the problem there, not globals. " - no it's
globals that make the poor design possible.

"Just because you now have local variables, doesn't mean that there is no
place for globals. " OK. Let's concede that point. Where does it get us?
There is a (small) place for globals, but I would argue that the use of
globals should not be introduced until the new programmer has grasped the
concept of local variables and what they can do for her/him. Otherwise you
just encourage over use of globals. Sure there are times when a global is
appropriate, or at least relatively risk free, but I'd still like to see an
example of where a global variable is essential.

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Monday, June 12, 2006 5:32 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...


On 12 Jun 2006 at 16:16, Heenan, Lambert wrote:

> Sorry , can't agree with that either. Public variables are there so 
> that code written for ancient systems, running languages that had only 
> one kind of variable - public ones - can continue to be run. It's a 
> backward compatibility feature. I know that may seem like a bold, 
> overarching statement, but look at the history of programming 
> languages. Why was the concept of 'local variables' dreamt up? Because 
> having all global variables was a nightmare The fact that lots people 
> (myself included!) have a tendency to cut corners and use them as a 
> quick and dirty way to get data moving from one module to another does 
> not mean that it's a good idea.  There's really no excuse for using a 
> global, as rewriting the code to use local variables requires very 
> little effort.
> 

I'm with Drew on this one. Just because you now have local variables, 
doesn't mean that there is no place for globals. Sure, "all global 
viariables was a nightmare" but we're not talking about "all global" here. 
There are a still situations where a global is the simplest and best 
solution.  Why limit yourself to only using some of the tools in you 
toolbag?
...
> it's based on the idea that a global, by its very
> nature can be modified from almost anywhere at all in code, and that  
> makes for a debug/maintenance problem.
> 

It's poor design that makes the problem there, not globals. The same can be 
said for any other alternative to a global such as Static Function, Class 
Property etc.

-- 
Stuart