Re: Multiple Inheritance - Howto marry tie::refhash::nestable with class::singleton

First, let's get the brokenness out of the way:

my $class = ref($proto) || $proto;
[download]

Please read ref($proto) - just say no!.

Now, it looks like you're enamored with shiny objects. Let's get back to the basics. You want a hash that is in every namespace? Then simply create a module that populates the hash and exports it:

package MyGlobalHash;
use base Exporter;
@EXPORT = qw(%MyGlobalHash);
%MyGlobalHash = (foo => "Hello, world!\n");
1;
[download]

And to use it:

package RandomPackage;
use MyGlobalHash;
...
print $MyGlobalHash{"foo"};
[download]

There. No singleton or tie or any of that junk needed. If that won't suffice, please clarify.

Also keep in mind that I hate global data. You should export behavior, not data. You should avoid global data as much as possible, because it creates nasty couplings that keep you from refactoring or reusing or testing code well.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on Re: Multiple Inheritance - Howto marry tie::refhash::nestable with class::singleton Select or Download Code

Replies are listed 'Best First'.
Re^2: Multiple Inheritance - Howto marry tie::refhash::nestable with class::singleton by hoppfrosch (Scribe) on May 31, 2005 at 13:14 UTC
Hi, I agree with your aversion to global variables, but since I'm currently reengineering stepwise a large piece of code (which makes intensive use of global variables) I have to use global variables (in my first reengineering iteration) as well to keep the code working. On the other hand: What speaks against a global variable keeping all information needed anywhere in the code? An alternative might be passing the data by parameters - which causes a lot of typo-overhead, since the data is needed anywhere in the code. You were partially right with your conclusion "you're enamored with shiny objects" - first I had a singleton as global data structure. Then I wanted to have an easy access to the data members like hash access. This results in my idea of the marriage ... But your suggestion only meets half the truth: I'm not able to populate the hash within an unique action - the contents of the hash has to grow/change during runtime ... Therefore I need a dynamic - and not a static - global data structure. Beside all aspects that speak against my suggested solution: As I'm keen to improve my perl knowledge, I would like to have a solution to my problem with "multiple inheritance" and correct initialization ... Hoppfrosch	[reply]
Re^3: Multiple Inheritance - Howto marry tie::refhash::nestable with class::singleton by merlyn (Sage) on May 31, 2005 at 13:43 UTC
... multiple inheritance ... "Multiple inheritance" is almost always the wrong answer to any question. You can only inherit from classes that are compatible with each other, perhaps even specifically designed to be used as a "mixin" class. You discovered two that don't play well together, so the answer is "you can't do that there". Therefore I need a dynamic - and not a static - global data structure. There's nothing preventing any part of your code from updating the data structure. The initialization will be executed on the first "use", but then anyone is free to change it. In fact, that's my beef with that! Anyone can change it! Good luck tracking down bugs. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^4: Multiple Inheritance - Howto marry tie::refhash::nestable with class::singleton by hoppfrosch (Scribe) on May 31, 2005 at 14:12 UTC
Totally agree with your disgust against global data structures which can be modified anywhere. The aim of my whole exercise is to encapsulate all the global data in a own class (singleton) and then to restrict the manipulation-access to the memberdata as far as possible ...	[reply]
Re^3: Multiple Inheritance - Howto marry tie::refhash::nestable with class::singleton by dragonchild (Archbishop) on May 31, 2005 at 13:26 UTC
What speaks against a global variable keeping all information needed anywhere in the code? merlyn isn't saying you shouldn't have a global repository for information. What he is saying is that you should be exporting functions/methods that the code can call to access said information. Then, if you ever need to log something or modify something as it's being set or retrieved, you have one place to do that. Or, let's say you're moving from a file-based system to a DB-based system. Bite the bullet and change everything to a pure singleton and call the methods to get at or set the data. This is even more important with setting data. (Though, this is starting to sound more like a stash vs. a configuration object ...) In general, if you think something isn't in Perl, try it out, because it usually is. :-) "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"	[reply]