format_string({foo => 'bar', %$set1, %$set2, format => $set3->{format}});

Saying there's exactly one right way to do it is an open invitation to a holy war. As long as you understand the benefits and tradeoffs of each method, you'll do fine. Blind adherance to an arbitrary rule such as "never write a function that takes more than one argument" is just silly.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

Saying there's exactly one right way to do it is an open invitation to a holy war.

That's very true. And I feel free to break any of my own rules if the situation warrants it. I state this one strongly because I try to avoid breaking it if at all possible. I find that reshuffling the data to support one-parameter logic helps me build better, more robust code.

I'll be happy to scale this one back to "try to code for single parameters if possible" if the rest of the monastery will give up equivalent dicta, like "use CGI.pm or die." ;-)

Also, what happens when you want to tell your print_multiple subroutine to print on a different file handle? Now your data structure is going to have to carry a file handle around with it, and everything that ever prints is going to have to worry about defaulting.

I submit that in the example you give, an object structure like the following may prove to be a little more loosely coupled and, in the long run, more maintainable.

  package Printable;
  
  sub print_on {
    my $self = shift;
    my($fh)  = @_;
    print $fh $self->as_string;
  }

  sub as_string { $_[0]->value }

  sub new {
    my $proto = shift;
    my $scalar;
    my $self = bless \$scalar, ref($proto) || $proto;
  }

  sub set_value { 
    my $self = shift;
    $$self = $_[0];
    return $self;
  }

  sub value { ${$_[0]} }

  sub print { $_[0]->print_on(\*STDOUT) }

  package Decorator;
  use base 'Printable';
  
  sub decorate {
    my $proto = shift;
    my($target) = @_;

    $self->new->set_target($target);
  }

  sub new {
    my $proto = shift;
    my $self = bless {}, ref($proto) || $proto;
    $self->init;
    return $self;
  }

  sub init { }

  package MultiString;
  use base 'Decorator';

  sub count {
    my $self = shift;
    exists($self->{count}) ? $self->{count} : 1;
  }
  
  sub set_count {
    my $self = shift;
    $self->{count} = $_[0];
    return $self;
  }

  sub as_string {
    my $self = shift;
    $self->target->as_string x $self->count;
  }

  package FormatBold;
  use base 'Decorator';

  sub as_string {
    my $self = shift;
    '<b>' . $self->target->as_string . '</b>';
  }

  package main;

  $thing = 
    MultiString->decorate(
      FormatBold->decorate(
        Printable->new->set_value("Hello, world");
      )
    )->set_count(5);

  $thing->print;
[download]

Yes, there's slightly more initial setup involved. Yes, OO dispatch means things are going to be slower. But as a programmer I can go faster because, when it's done right, OO leaves you with small methods, that take a small number of arguments and which do exactly they say on the tin.

Done badly, well, Object Ravioli can be just as bad as (worse than?) procedural spaghetti. You just have to exercise Good Taste.

Um... am I missing something here? You seem to have merely reinvented Object Oriented Programming without the really good bits like Polymorphic method dispatch.

Well spotted.. building a data model that's independent of the actual logic is indeed the first step toward grokking OOP.

Taking this idea to a full OO perspective produces the Model-View-Control program architecture:

• the Model is responsible for all data storage and manipulation.
• the View is responsible for all communication across the boudnary of the program's address space.
• the Control accepts messages from the View, and tells the Model how to set or manipulate its stored values.
Ivar Jacobsen disccusses a similar architecture (at length) in Object-Oriented Software Development: A Use Case Driven approach.

More generally, we're talking about separation of concerns. You can apply the same concepts perfectly well within the framework of procedural programming. The OO/procedural/functional styles are all just syntactic sugar for the basic computing machinery -- state machines, pushdown automata and the like -- and establishing a clear separation of concerns between your data and the logic that manipulates it is a best practice of any programmming style.

As pdcawley mentioned, a lot of what you are trying to achieve can be done through good OO design principles and inheritance. And for me, I'll take the speed hit for a method call any day if it makes my life easier as a programmer. Is anyone going to notice if my program takes 100ms longer because of OO method lookups? I really don't think so. In the end, I always come back to doing what makes sense for the programmer. The latest hardware can usually take care of any speed problems.

The only important thing is idea. Why not meditate on idea, not on realization?

And idea, as I understand it, is making program based on data structures used in this program instead of actions required from this program. Yes, I agree, this is much more like OOP. And in fact we have three (and may be more) different designes of how to write program:

1. logic oriented
2. data oriented
3. object oriented

So, the question to mstone: describe please reallife task where your style give advantages.

P.S. I have a plan to make post in Meditations how style like this one used by me can help in writing CGIs.

I can give you an example where you are going to have a hard time with only using one parameter.

I want you to write a rotuine that only takes one parameter that will allow me to determine is several scalars are the same entity or not.

So I have

my ($x,$y,$z);
$x='a';
$y='b';
$z='c';
[download]

I want to be able to take any selection (including duplicates) and determine the number of distinct values. Thus

Input          Output.
$x,$y,$x,$y => 2
$x,$y,$z    => 0
$x,$x,$x    => 1
[download]

Oh, dont bother trying to hard to do this with just one parameter. It cant be done. :-)

And if that isnt a red rag to a bull then I dont know what is.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Aggregation is a wonderful thing: ;-)

    sub find_unique_items_in {
        my $set = shift;
        
        my (%uniq, @out) = ();
        
        for $i (@$s) {
            $uniq{ $i }++;
        }
        
        push @out, sprintf (
            "%d unique entities (%d duplicates):\n", 
            scalar keys %uniq,
            scalar ( grep { $uniq{$_} > 1 } keys %uniq ),
        );
        
        for $i (sort keys %uniq) {
            push @out, sprintf ("%-16s -- %d", $i, $uniq{$i});
        }
        return (join ("\n", @out));
    }


    @list = (0) x 10;
    
    for (1..10) {
        $set = [];
        push @set_list, $set;
        
        for $i (0.. rand(5)+10) {
            push @$set, \$list[ rand @list ];
        }
    }
    
    for $s (@set_list) {
        print "\n", '-'x72 ,"\n\n";
        print join ("\n", @$s), "\n\n";
        print &find_unique_items_in ($s), "\n";
    }
[download]

Not only does it keep your parameter lists trim, it lets you store your data sets so you can use them again.

Now, I don't pretend that the above is an exhaustive search for matching entities, but as far as I know, it's fundamentally impossible to create a parameter list that can't be stored as a data structure. And thinking about those data structures -- especially the possibility of using them again -- helps you build well-organized code.

GUI programming is the first example. Web applications also benefit, because they're a subset of the Model-View-Control architecture. Signal-based programs and multi-threaded programs also benefit from keeping the data isolated from the logic. So does any code that needs to be reentrant -- scripts written for mod_perl, for instance.

Think of it this way: your function signatures are your program's internal communication protocol. So how good is your program's protocol? Is it structured and well-organized, or is it more like the transcript of half a dozen random bar conversations?