in reply to Re: Re: Re: Naming Subs
in thread Naming Subs

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

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

[reply]

      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.

[reply]
        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]
      You are aware that the symbol table is basically a dispatch hash on steroids? That invalidates your wasted space comment.

      That's an interesting view of things. Would adding a third, or maybe a fourth layer of indirection make things more readable and maintainable? It's precisely because the symbol table is a dispatch hash that I don't think one is necessary in the code I posted. It is redundant.

      -- dug
[reply]
        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.

[reply]
Re: Re: Re: Re: Re: Naming Subs
by PodMaster (Abbot) on Jan 13, 2003 at 09:20 UTC
    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.

[reply]

In Section Seekers of Perl Wisdom