On Dec 17, 2004, at 4:02 PM, David Landgren wrote:
The biggest problem I see is how to avoid having to sketch out everything up front. I think it's only after I get 3 or 4 Printer::Status::x::y modules under my belt that I'll *begin* to get a feel for where the divisions lie and what methods can be hoisted up the namespace to Printer::Status::X or Printer::Status.
For instance, the older 4500 model had three cartridges: drum, transfer and fuser. The new one only has two, they did away with the drum. Not all models have the same consumables; two models may have none in common. I'm not sure how to represent this elegantly. What I do know is that I don't want to build up a towering hierarchy of classes for something which is, at the end of day, really pretty trivial.
If I were you I'd not use classes to model that part of it. Just have a Printer::Status::HP4500 (or HP::HP4500 or whatever) object with a components() or consumables() method that returns a hash mapping name to properties. E.g.:
$stuff = $printer->consumables();
# $stuff is now:
{ drum => {
.... whatever you know about the drum
},
transfer => {
.... whatever you know about the transfer
},
fuser => {
.... whatever you know about the fuser
},
}I think Perl's built-in ways of interrogating hashes should be sufficient for what people will want to do with the information.
-Ken
