FW: SPUG: Scope question

[Peter Darley]

Friends,
	As they say, there's more than one way to do it...

Jason said:
> Yes, you should consider this an opportunity to rethink your coding
> style and perhaps learn better coding techniques.  As any experienced
> programmer should be able to tell you, global variable are a Bad
> Thing.  Many languages (e.g. Java) don't even have globals.

	I agree, there is always room to improve ones coding techniques.  One
reason that I want to use the globals is that I've gotten mixed results with
passing around hash references and as hashes, and I'm not comfortable with
my understanding of when elements of a hash are copied, when the elements of
a copied hash are just references to the real contents of the hash, etc.  I
figured it would be simpler to rely on globals to ensure that every time my
session info hash gets used I know that it's the correct one.

Collin said:
> However, there are perfecty valid uses for global variables. In a module
> that is used for manipulating data in a relational database, how tired
> do you get of passing around the database handle into each routine, or
> accessing it from buried within your object. Just put it in a global,
> document that to be your API, and use it when needed.  Another fine use
> of a global is to hold application configuration data.

	Coincidentally, I'm wanting to use the globals to hold my database handle,
and to hold session info for my application (much like application
configuration data). :)

Then Jason said:
> That might be reasonable advice for non-OO languages.  I still say
> that with OO languages, there is *no* good reason for using globals.
> Pass the database handle to an object constructor once, and then the
> client can forget about it after that -- or else get the handle from
> a class method.  Ditto with configuration data.

	I don't write OO Perl, as I don't see any particular value in it unless
you're putting modules out into the wild.  I find it far easier to conceive
of functions as being things that transform data, so I can have any number
of functions that get data into a certain state before passing it off to
another function.  The other option seems to be having either tons of
objects that are very similar, but have different methods of initialization
and/or processing, or having small numbers of huge unwieldy objects that
break the idea of having an object fundamentally doing one thing (This is
poorly phrased.  I don't meant to say that an object should only have one
function, but that you don't want to combine dispirit capabilities into one
object).

Thanks for listening to my uninformed ramblings :)
Peter Darley


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org