I can think of a couple of ways of dealing with this. Each printer module could have a method (say, attrs) that, when called, returns an array of method names to call, in order to iterate over all that the module has to offer:

  for my $attr( @{ $printer->attrs() } ) {
    print $printer->$attr();
  }
[download]

But that won't quite cut it for printers with sophisticated toner details (although someone on the m-a@ list pointed to Hash::AsObject which may do the trick). But if anyone can point to prior art or Another Way To Do It, I'm all ears.

I think this is one of those instances where new() doesn't buy you much as a constructor. So consider the following:

my $want = [
   { printer1 => Printer::Status::Acme::x1000->new( qw[serial_number b
+ios_revision] ) },
   { printer2 => Printer::Status::Acme::x1200->new( qw[firmware_revisi
+on toner] ) },
   { printer2 => Printer::Status::Acme::c800dn->snmp( qw[mac_address s
+erial_number] ) },
];
my %result = Printer::Status->as_hash($want);
# or
my @result = Printer::Status->as_array($want);
[download]

Sometimes you want to get the results back and refer to them by name, other times in the order in which you specified them. (Regardless of how Printer::Status actually went about fetching all the information). The contructor you choose determines how you get things back. Somewhat like DBI's fetchrow_arrayref and fetchrow_hashref.

The ugliest thing is the division of duties between the printer module and the acquirer. An object starts out half-constructed. The acquirer then asks it what it wants to fill in the blanks. It returns a list of URLs. The acquirer fetches them (in parallel with a number of other printers, possibly in parallel with itself) and then returns them back to the printer object. At this point the printer object is fully constructed.

On the other hand, if you only have one single printer, you don't care to go through all those hoops. Instead you just create a printer object and try to access its fuser_temperature method. The object, seeing that it has been called upon to provide some information it does not yet have, then creates its own temporary Printer::Status object to use it to fetch what it needs and thereby complete its own initialisation. That A can use B, and B can A, seems a little... odd.

Note that I do think it's also pointless to try and force all printers into a common mould (in terms of what information they can return). The stuff offered is just too different. Of course, I hope that I'll be able to lay down guidelines of some sort, so that if at least two printers offer the same piece of information, it will have the same name (e.g., I'd like to avoid serial_no versus serial_number).

In the end, if you're interested in a printer, you shall have to consult the manpage to find out what it offers.

So, if anyone has pointers to module hierarchies that do something similar, or observations (yeah but if you do it like that you won't be able to do this), I'll be very interested to hear what you have to say.

I'd like to try to avoid to build one in order to throw it away, so if the good monks can advise me, maybe the first version will be a winner.