Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re^2: Are global variables "bad"?

by jpearl (Scribe)
on Apr 21, 2009 at 17:14 UTC ( #759059=note: print w/replies, xml ) Need Help??

in reply to Re: Are global variables "bad"?
in thread Are global variables "bad"?

I have read a bit about singletons, though to be honest my only exposure was basically checking out globals and why they might be bad. For instance when reading this there was a link to this. Kind of a programming culture of fear :-P

Thank you for the links, I'll definitely check out Class::Singleton Though you are probably right on just creating my own solution.

Replies are listed 'Best First'.
Re^3: Are global variables "bad"?
by DStaal (Chaplain) on Apr 21, 2009 at 17:32 UTC

    I don't actually see any particular reason to use a singleton in this case: You are parsing a file, and want to store it someplace. There is no particular reason (from what you've said) why parsing a different file, or even reparsing the file should be prevented. (Besides the fact of memory useage/speed, which to me isn't a reason for a singleton, just a reason to keep using the same object.)

    Basically, it's extra complexity to prevent future uses. I don't see why either would be something you want.

      Agreed. The singleton is, when you get right down to it, really just a hack to add global variables to Java in an "object-oriented" way, dignified with a fancy name and notable mainly for being the design pattern people are by far the most likely to be able to remember off the tops of their heads.

      There are very few cases where singletons add value in a language like Perl. If your code is worth the effort of moving away from global variables, it's worth the effort of generalising completely (for example, allowing people to have multiple data sets open at once).

Re^3: Are global variables "bad"?
by ELISHEVA (Prior) on Apr 22, 2009 at 03:26 UTC

    If one expects the file format to change over time to accommodate new research data or evolving use cases, using class methods or a singleton object would be a good idea. OOP architecture makes it much easier to support multiple file formats in parallel.

    Without objects, you have three options for supporting two file formats:

    1. Define a second set of parsing functions with ugly names like parse_blah2. Then go all over your existing code inserting if...else statements to select the right set of functions.
    2. Define the functions for format II in a new package. Now go back to the consumer code and replace all of your calls to parse_XXX(...) with eval("${sParserPackage}::parse_XXX").
    3. Define a second set of parsing functions and create a dispatch table. Now go all over your code and replace the direct calls to parsing functions with calls to dispatch table members. You've gotten rid of the bulky if...else and eval(...) statements, but you are still making massive code changes. You've also lost some debugging ease since dispatch table methods are going to show up in standard debugging tools as anonymous code references rather than named functions. You simply aren't going to get error messages like Can't locate object method "parse_blah" via package "MyModules::Parse2" Instead you'll get an obscure message about Use of uninitialized value in subroutine entry

    Or you could define your parsing process in an object. The only change that would need to be made in your program would be a small bit of code to check the version number and retrieve the correct parser. Any other code using the parser methods would stay the same since it only cares that statements like $oFoo->parse_blah and $sParserClass->parse_blah() behave in a predictable fashion.

    Classes and objects, even singleton objects, give one the ability to override and redefine methods without changing a byte of consumer code.

    Best, beth

    Explanatory note: in Perl, a class method is just a package subroutine whose first parameter is a class name. Calling Foo->fribilate(...) tells Perl to pass "Foo" as the first parameter and to allow overloading. It also lets one use a variable for the package name. ${somevar}::fribilate(...) generates complaints about bare words where operators were expected. That is why we had to use eval(...) in non-object option 2.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://759059]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2018-06-23 08:38 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.