That invalidates your wasted space comment.

I'm not sure it does. Effectively what you pointed out is that every sub has a hash entry (in the/a symbol table) that is built by the compiler. Using a programmer defined/constructed hash for dispatching is therefore duplicating these entries.

It also means that the runtime overhead for looking-up and executing a sub is duplicated.

Last but not least, the programmer defined hash table has to be maintained manually as new actions are added, old ones deleted or names are changed. Using SymRefs this is all taken care of by the compiler which has to appeal to some degree to the lazy programmer:^)

Don't misunderstand me, prior to this thread I would have considered myself firmly on the 'No SymRefs--use a hash' side of the argument. Currently I would declare myself as undecided. I am sure there are good counter arguments besides the obvious "so it takes a little more space and a little more time, it's safer", I just haven't seen one yet.

Your scoping argument has some merit, but given the nature of the OP's application, it's unlikely that the number or nature of the dispatch table is likely to change radically during any given run of the program.

I can see how the application could evolve to the point where it required new actions to be created on the fly, but that's equally possible with either method, after all that's essentially what AUTOLOAD does isn't it?

It's definately an interesting debate.

To clarify, when I use dispatch hashes, I almost always store anonymous functions in them. I don't like taking references to named subs for dispatch hashes, it requires me to keep the refs and subnames in sync and offends my sense of Once And Only Once. I should have mentioned that from the get go.. that's the basis for saying the space waste argument is invalid.

Last but not least, the programmer defined hash table has to be maintained manually as new actions are added, old ones deleted or names are changed.

Ah, but that's the problem! I have to take care that other stuff the user should not know about does not become available via symref call as I add it. With the hash, it's obvious: nothing I haven't put in there can be reached. Period.

And once you consider my omitted assumption (mea culpa, it does make a difference to my argument and should have been stated explicitly) that I'm storing anonfuncs in the hash, then there's nothing less automatic about it. Instead of writing sub action_eatfoot {}, I type eatfoot => sub {} and that's it.

Makeshifts last the longest.

I don't think so. To clarify, when I use dispatch hashes, I almost always store anonymous functions in them. I don't like taking references to named subs for dispatch hashes, it requires me to keep the refs and subnames in sync and offends my sense of Once And Only Once. I should have made that clear from the get go I guess.. Once you take that into account, it becomes a technique for lexically (or semantically, if you pass a reference to the dispatch hash around) scoping functions. And that's a good idea for all the same reasons we use scoping in other contexts.

Makeshifts last the longest.

That makes sense, thought the syntax of creating your hash must get a bit messy unusual if you have large and/or many subs. Only a bit though.

I was just thinking about how you would handle modularising the functionality, in terms of the source code rather than semantically?

I probably haven't thought this through properly yet, but to try and explain what I mean, say your writing an editor. The dispatch table is used to invoke actions depending upon user input. The user input can take the form of keystrokes, mouse gestures, CLI comands and possibly menus. Ignoring for the moment any problems that might arise from storing/translating keystroke or mouse gesture info into a hash key. It makes a certain amount of sense to segregate the functionality along those lines into seperate modules, if only for ease of editing. I realise that the segregation would more likely be on the basis of different criteria (eg. edit action on current file, configuration action on current file, global configuration action etc.)

The point is, once you have sub code in different source files, how would you go about building this into a dispatch hash for use in the main input queue processing loop?

Add to this the requirement to allow the remapping of the keyboard commands and the desire for the ability to define keystroke/menu commands to user defined 'macros' (I use the term loosely) and I having trouble envisioning how to build and maintain the hash table.

This is actually quite close to something I'm working on right now, hence my interest.

---

Examine what is said, not who speaks.

The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.