Symbolic references are loaded with caveats. If you know them and know to avoid them, you're fine, of course.

Dispatch hashes are still better. A hash is a portable namespace. Using a dispatch hash promotes separation between disjunct parts of your application's logic: in this case, the hash encapsulates the game logic, while the toplevel code handles the user input logistics.

Not to mention that just understanding that you can "store subs in a hash" is a large conceptual step that will open up an entire world of new possibilities.

Makeshifts last the longest.

Symbolic references are loaded with caveats. If you know them and know to avoid them, you're fine, of course.

Or if you know how to use them, of course :-)

Dispatch hashes are still better. A hash is a portable namespace. Using a dispatch hash promotes separation between disjunct parts of your application's logic: in this case, the hash encapsulates the game logic, while the toplevel code handles the user input logistics.

I am still not convinced that game and user logic need to be separated in *this* particular case, which is why I'm arguing that my posted method *may* be a more maintainable method.

Not to mention that just understanding that you can "store subs in a hash" islarge conceptual step that will open up an entire world of new possibilities.

Ahh, this is good. This is educational for new Perl hackers, which is exactly what is needed. Which is what I'm arguing. I hope that's what folks see in this thread.

Thanks, Aristotle

-- dug

OK, in this specific context: if you use a symbolic ref, it's easier to accidently allow the user access to subs they shouldn't have access to. For example, in a text-based RPG, there's quite likely a win sub, which is called when the user wins. If you use a symbolic-ref based implementation, unless you're careful, the user can simply type "win" to win the game. In a hash-based system, you'd have to explicitly put the win key in the hash, so it's quite unlikely to happen accidently.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

1. You asked me why it was bad in *this* case. My answer is simple, it is not just bad in this case, it is bad in all cases, including this one. This is something about principle. It is just like you ask me why "goto" is bad in *this* case, I will say, no, it is bad in every case, you should never ever use it.
   
   Whatever you archieved here, can be easily archieved by using a hash containing all coderef's (hard ones). What is the point to violate principles, when you can complete the same task by following the principles, and gain more maintainablility and flexibilty?
   
   
2. Modern programming no longer appreciates smart tricks that much, on the contrary, we strongly stress the importance of maintainability more than ever.
   
   To make your piece of code work, it requires to turn off "use strict". You may argure that we can just turn off use strict refs for that particular lexical scope to reduce the danger, but still someone maintain your code may add some bad code into that lexical scope, and miss the chance of correcting it in the first place, all because "use strict" is turned off.
   
   To be frank, after couple of months, even you may forget that that piece of code is a mine field. Does this not happen all the time to us?
   
   A really dangerous thinking in programming is to assume everything will go well by its own. That is never true.

So, are useful (core) modules like Exporter and Memoize "bad" code? Because they do turn off "ref" strictness - you can't do the stuff they do if you always have all levels of strictness turned on. Use of symbolic references isn't a trick. Far from that. It's something very powerful. So powerful that it's a good idea to have it turned off most of the time. But not always.

You aren't a good programmer because of the restrictions you put on yourself (otherwise, we'd all be programming Brainfuck); you are a good programmer when you know when to restrict yourself, and when not.

Abigail

It is just like you ask me why "goto" is bad in *this* case, I will say, no, it is bad in every case, you should never ever use it.

Objection. I have never used goto itself, but last, next and so on are little more than glorified gotos and I use these religiously. And I'm fairly certain there may at some point be a case when goto will be more appropriate than any "structured" approach and in that case, I won't hesitate to use it.

Also don't forget that OO in Perl is nothing but symbolic lookups.

You are right of course that dispatch hashes are better.

Makeshifts last the longest.

1. You asked me why it was bad in *this* case. My answer is simple, it is not just bad in this case, it is bad in all cases, including this one. This is something about principle.

This is similar to a parent saying "Cause I'm the adult" when explaining the reason for a rule to a child. It doesn't *explain* anything, and seems to me to be a cop-out. I don't believe that there is anything principle about this argument. It has evolved over time to the point where people are so used to hearing "It's bad" that they just believe it.

It is just like you ask me why "goto" is bad in *this* case, I will say, no, it is bad in every case, you should never ever use it.

Unless you need to trick caller() from inside AUTOLOAD? Or even then, would you forsake its goodness for a more convoluted solution because you know "It's bad"?

Whatever you archieved here, can be easily archieved by using a hash containing all coderef's (hard ones).

With the added maintainance and wasted space of a dispatch table stored in a hash, yes.

What is the point to violate principles, when you can complete the same task by following the principles, and gain more maintainablility and flexibilty?

I don't adhere to "principles" that make things less maintainable and less flexible, and disagree with the statement that the hash based dispatch table improves those things.

2. Modern programming no longer appreciates smart tricks that much, on thecontrary, we strongly stress the importance of maintainability more than ever.

That's a pretty nebulous statement. But I do agree that maintainability is important. I am arguing that adding a hash as a dispatch table decreaces maintainability in this case.

To make your piece of code work, it requires to turn off "use strict". You may argure that we can just turn off use strict refs for that particular lexical scope to reduce the danger, but still someone maintain your code may add some bad code into that lexical scope, and miss the chance of correcting it in the first place, all because "use strict" is turned off.

"use strict" is not turned off. "strict refs" is turned off explicitly, which explicitly allows use of symbolic references. As an aside, I think it is pretty funny that in order to leave "strict refs" turned on and use the dispatch method I did, I have to use the one exception to the no-symbolic-refs rule that "strict refs" enforces. It exists so people people can use goto and a symbolic reference to a subroutine under stricture.

To be frank, after couple of months, even you may forget that that piece of code is a mine field. Does this not happen all the time to us?

I may be wrong, but I don't think it is mine field. Nothing you have said has convinced me of that, to be sure.

A really dangerous thinking in programming is to assume everything will go well by its own. That is never true.

I don't know that means.

Thanks very much for the response, pg.

-- dug

With the added maintainance and wasted space of a dispatch table stored in a hash

You are aware that the symbol table is basically a dispatch hash on steroids? That invalidates your wasted space comment. Actually, depending on the case, you can let a dispatch hash go out of scope, freeing memory naturally. You can get rid of the memory occupied by regular subs and their symbol table entries, but it's rather a lot of work in comparison. Not to mention that keeping user exposed symref interfaces safe takes at least as much maintenance work as setting up a dispatch hash.

Makeshifts last the longest.

Added maintenance and wasted space? Oh come on (get real)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy.