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

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

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

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

    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