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

Certainly I can give you my opinion why it is not good. (When I said, in my prev post, that you knew it was bad, I was sincere, but unfortunately you thought I had an evil mind...Well)
  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.

Replies are listed 'Best First'.
Re: Naming Subs
by Abigail-II (Bishop) on Jan 13, 2003 at 14:09 UTC
    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

[reply]
Re^4: Naming Subs
by Aristotle (Chancellor) on Jan 12, 2003 at 18:46 UTC
    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.

[reply]
Re: Re: Re: Re: Naming Subs
by dug (Chaplain) on Jan 12, 2003 at 18:42 UTC
    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
[reply]
      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]
        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]
      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