Re: Re^5: Naming Subs

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.

Examine what is said, not who speaks.

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

Comment on Re: Re^5: Naming Subs

Replies are listed 'Best First'.
Re^7: Naming Subs by Aristotle (Chancellor) on Jan 13, 2003 at 22:43 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^7: Naming Subs
by Aristotle (Chancellor) on Jan 13, 2003 at 22:43 UTC

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.

[reply]