in reply to Is it ok to mix functional and oo programming in one package?

I've recently adopted a coding style that results in code that can be executed both purely procedurally or in an object oriented fashion. I find that as long as I consistently stick to the style, my code is much more flexible for both internal and external use.

In a nutshell, I alwas add the line my( $self, %args ) = @_; *unless* it's an new *or* import. Then I substitute $self with $class.

The resulting subroutines end up looking like this:

sub do_something { my( $self, %args ) = @_; my( $scalar ) = $args{scalar} || eval { $self->{scalar} } || $self->SCALAR; my( @list ) = ( eval { @{ $args{list} } or 1 } ) ? @{ $args{list} : $self->LIST; }

Then calling code can choose to pass in parameters it wishes to override, or define a subclass that overrides the defaults (such as SCALAR and LIST.)

This approach has worked well for me so far. It supports both OO and procedural. It doesn't break inheritance, in fact it uses inheritance to reduce the number of arguments necessary if changing the defaults makes sense.