in reply to Whats wrong with symbol refs here?

As long as your co-workers are prepared to handle sophisticated approaches like this, there is nothing wrong with what you are doing. I have done the same in the past and been happy with the result.

To answer the question asked elsewhere about AUTOLOAD, there are several advantages. First of all every time you need to change the symbol table you throw away the method cache. If you think most of your methods are going to get called eventually then it makes sense to only pay that once.

That one is relatively unimportant though. The big one is that you now are not forced to put all of your dynamic logic in one place. With AUTOLOAD you need to put all of your dynamic logic in the first AUTOLOAD. And if you have a subclass which should work just like its parent but with a minor tweak...you need to duplicate logic. But with this code the dynamic bit only affects what it needs to at the level it wants to and can override and be overridden in a fine-grained manner. This gives quite a bit more design flexibility than AUTOLOAD offers.

  • Comment on Re (tilly) 1: Whats wrong with symbol refs here?

Replies are listed 'Best First'.
Re: Re (tilly) 1: Whats wrong with symbol refs here?
by Anonymous Monk on Feb 05, 2002 at 21:24 UTC
    THanks for the comments.. Your line of thinking is just as mine is. I think it makes things easier to read... I also have more control than AUTOLOAD ... I think, provided you know the syntax, this solution is actually easier to maintain.

    Basically, doing this isn't a Bad Thing(tm), just that some people may not understand it. No problem. Thats what the Perl Monks and ORA are for ;-)
      Just make sure that you comment it. Heavily. You're doing something "Weird and Strange"(tm). Don't assume that anyone is as smart as you, or thinks in the crazy ways you do. Always assume that the person after you was told "Here's the Perl manual. Read it, then maintain this code." Be nice to them. :-)

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.