in reply to Re^7: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
in thread what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?

I really don't buy this "singletons sucks" stuff, at least for configuration object :)

For me the problem is that if there are dozens of:

my $config = MySingletonConfigurationClass->instance; my ($foo, $bar) = ( $config->foo, $config->bar );

sprinkled all around my code overriding things for testing, tweaking configuration based on the context, etc. all become much harder than if I'd passed in my own configuration object, used dependency injection, or whatever.

Most people seem to use singletons as big-fat-globals in disguise - and give themselves (or the poor souls who have to maintain their code) all the problems that globals give you.

Take a look at http://del.icio.us/adrianh/singleton for some singleton rants.

  • Comment on Re^8: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
  • Download Code

Replies are listed 'Best First'.
Re^9: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
by wazoox (Prior) on Mar 07, 2006 at 12:53 UTC

    overriding things for testing, tweaking configuration based on the context, etc. all become much harder than if I'd passed in my own configuration object

    Well if you want to change your configuration depending upon the context, then of course you don't want a singleton... which is all about never changing (or overriding) anything wherever you are. Of course it's globals in disguise, but it's globals on steroids too, because you can share your globals across packages as needed :)

      Well if you want to change your configuration depending upon the context, then of course you don't want a singleton... which is all about never changing (or overriding) anything wherever you are.

      No it isn't. A singleton is about there only ever being one instance of a class. Nothing wrong with having a singleton instance whose state you can change.

      Of course it's globals in disguise, but it's globals on steroids too, because you can share your globals across packages as needed :)

      Of course you can share globals across packages.

      { package Foo; $foo = 1; } { package Bar; print $Foo::foo, "\n"; }

        Well you're right I wasn't very clear :) You may of course change a singleton, but changes to it are obviously global to your app. If that's not what you want, then you don't want a singleton.

        Of course you can share globals across packages.

        Yeah sure, but in an OO-environment that means you're breaking encapsulation. Singletons don't.