in reply to Re: passing subroutine args as a hash: why not?
in thread passing subroutine args as a hash: why not?

For your typical sub, there is a great problem with that many params. However, I can see how a perfectly good object would have a constructor with quite a lot of args. Perhaps not 61, but they often have a lot more than a typical sub (just look at all the options in the HTML::Template constructor).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

  • Comment on Re: Re: passing subroutine args as a hash: why not?

Replies are listed 'Best First'.
Re: Re: Re: passing subroutine args as a hash: why not?
by djantzen (Priest) on Jun 05, 2003 at 18:51 UTC

    Actually, I'd say the paucity of arguments is just as important in constructors as in subroutines and for reasons beyond the mere fact that in Perl a constructor just is a class method. For one thing, any object that takes more than a couple of seconds of consideration as to how it may be instantiated will discourage its own use. In either case it indicates generally that insufficient thought was given to breaking up responsibilies among constituent parts. Not always, but often the first thing to consider if you've got vast numbers of arguments to a constructor is the use of inheritance to encapsulate the differences among data and behavior normally conveyed via parameters.

    Consider, say, a Logger class with multiple different types of logging available, e.g., types of warning raised if any, location of error logs, email or page contacts, etc. Better to create a CarpLogger subclass that inherits behavior and already knows what to do than to clutter Logger with if/else code deciding actions based upon arguments. A smaller, simpler constructor improves maintainability and usability.


    "The dead do not recognize context" -- Kai, Lexx

      Looking back at HTML::Template, I count a total of 31 params passed to its constructor. Granted, some of them would never be used together (such as arrayref and filename), but it will accept that many. Despite this fact, the module doesn't strike me as having a bad design. Most of those params would need to be passed to a subclass anyway, and the few params left over (perhaps some of the caching options, strict, or die_on_bad_params) just don't make it worth the trouble of inheritance (IMHO).

      Further, inheritance is a major kludge in Perl5 (kludgier than the rest of its object system), and should generally be avoided if possible.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      Note: All code is untested, unless otherwise stated

        I can't speak to the usability of HTML::Template, never having worked with it, so I'll take your word for it. However I take strong exception to the idea that inheritance should be avoided. True it is kludgy, as is all of Perl's OO support, but it works predictably and reliably, and the decision to make use of it should depend upon architectural decisions and not discomfort with its implementation. Indeed the only problems I've ever encountered with inheritance have been in modules with constructors that have not been cleanly designed to support it, for example, have used the single argument form of bless. For more see inheritance: constructors.


        "The dead do not recognize context" -- Kai, Lexx