After you fix the error message you're getting by removing "our" from line 9 (our %$variable ... just won't work), then you can move onto the strictures violation on line 13: print %$variable is still a strict violation even if you've already created the variable. If your code is going to be full of those constructs, you're going to have to run without strict 'refs', or jump through little "no strict 'refs'" contortions all over the place.

You say this is something you really want to do. So do it. Just don't ask "strict" to condone it.

I'm interested in hearing why your code might fit into the 0.5% of code that needs to implement this powerful and dangerous feature. Are you writing an exporter? What is the benefit? Is it worth it? Are you sure it's not a problem that could be solved by another level of indirection? You might just need a 3rd floor, not a 2nd basement.

so how is that superior to using an explicit "name" level in your hash? Using a variable as a name simply introduces exactly the same effect as adding a "name" level to a hash, but you have no easy way to debug your code. If you use a conventional hash you can use modules like Data::Dump (or better still, use an IDE or the debugger) to inspect the contents of the hash for debugging purposes. Consider:

I was hoping that you might come up with some interesting and compelling reason -- some problem that can only be solved by getting your hands dirty in the muck of the symbol table. Instead, I'm seeing a description of a problem that can be solved with one more layer of hard references; a hash of hashes, for example. That, you can read about in perldsc. GrandFather is right; you just need a higher level layer of abstraction; a hash of hashes.

Your situation doesn't meet the criteria for a good reason to use symbolic references in any code that you intend to keep around on your hard drive for more than a few minutes. You've stated pretty clearly, however, that you're not open to other alternatives; you know what you want, and just needed us to show you how to do it. But as the old saying goes, "now you have two problems."

It's easy to forget that the symbol table is little more than just a special hash. All of Perl's package globals live in hashes. Perl is implemented to hide that from you most of the time, but behind the scenes, they're there. You don't usually need to fiddle with Perl's hashes when you can create your own to fiddle with instead.

PLEASE, don't tell me I dont want to do this.
I want to do exactly what I said above.
Not to use hash of hashes or anything else.
I DO want to use a variable as a hash name
and I'm aware of the risks.

To help you understand why you've copped a few downvotes,
it would have been more polite to explain up front
why you want to use symbolic references, rather than
to issue a command to the unpaid volunteers who answer
questions here.
Understanding the why behind your
question makes it more interesting for us and makes
it more likely that others who read this node in
the future will learn from it
(this topic is discussed in more detail at the XY Problem).
Please remember that this site is a community
of Perl programmers, a community that
encourages everyone to grow and learn from
each other.

Anyway, welcome to the monastery.
If you become involved in Perl monks, not just asking
for help, but answering the questions of others,
you should have a lot of fun and your Perl will improve out of sight.

You see, is not that I'm not open to alternatives. Is just that I read a lot of foruns adressing this problem (of use variavles as variables name) and as much as I tried, I was unable to use hash of hashes to solve my needs.

So I wanted to use the dirt way because I needed to solve it fast. But YES, I would like to improve my code to not have to disable strict. And I am thankfull for your help.

PLEASE, dont't tell me I dont want to do this. I want to do exactly what I said above. Not to use hash of hashes or anything else. I DO want to use a variable as a hash name and I'm aware of the risks.

So you know that article, and countless nodes, that explains why doing this is dangerous? It also explains exactly how to do it!

So go ahead and RTFM the FAQ, that is why it exists, so you can read it

Early in my tenure at the monastery, I made the mistake of critizing BrowserUK for a similar use of symbolic reference. His rather insulting reply Re^3: Passing arguments to functions. does make a good case for their use.