http://www.perlmonks.org?node_id=28634


in reply to Re: Handling cascading defaults
in thread Handling cascading defaults

I would actually organize that slightly differently:
package Err; sub new { return bless {}, shift; } sub err { my $self = shift; my %args = @_; # Do something with %args here }
And then in other code you would do this:
$handler ||= new Err; # time passes &do_right_thing() or $handler->err(title=>'Oops',msg=>'something went +wrong');

Replies are listed 'Best First'.
RE: RE (tilly) 2: Handling cascading defaults
by merlyn (Sage) on Aug 19, 2000 at 19:31 UTC
    At this point, since you've not shown the need for inheritance implementation reuse or even interface reuse, I'd stay away from the complexity of objects. My personal rule is not to pull in OO technology in Perl until the line count of the program exceeds about 1000 lines, and using all the OO features of abstraction, inheritance, and data hiding all becomes useful. So far, all you've done is named a data structure. {grin}

    -- Randal L. Schwartz, Perl hacker

      I agree that OO is not a great wheel for this case. But I do see two points with that code. The first is that you probably want your error message put into the handler, and not the constuctor. (Which is why I posted.) The second is that you get an indirection layer.

      OTOH if the indirection layer is all that is desired, then a reference to a sub does that without the OO machinery hanging around.

      Incidentally I don't like to put full OO designs into a ton of code either. However I do like trying to put some sort of indirection in early. But to do it in a way where I can behind the scenes figure out how to do it better later.

      For instance some of the arguments will likely go into many messages, so the code I posted could have been improved to

      package Err; sub new { return bless {@_}, shift; } sub err { my $self = shift; my %args = (%$self, @_); # Do something with %args here }
      Now, while OO probably still isn't a great fit, at least I have done more with it than provide a level of indirection in how the subroutine is named. :-)