While it is true that *real* OO is nice when objects do stuff, OOP in Perl, even if halfway done without doing stuff (it can do stuff, but doesn't have to), is a decent way to implement C structures in a halfway clean sort of way without having to deal with the ugly gorp that is an HoH. That being said, my objects contain HoH's all the time, but I really hate it when outside methods must delve into them each time the hard way, or to iterate through their keys.

I suggest you take the plunge, but retain the knowledge of the old ways. Properly mixed, they are powerful. You never really have to go "pure OO" if you want to, especially not in Perl. Trivial OO (i.e. objects that just work like C glorified structs) is ok for starters until you decide to add more real-OO functionality. Of course, OO isn't really OO until you are using inheritance and other fancy over-hyped concepts :)

Note that over half of the developers that think they are doing "real OO" are just using overglorified structs -- which means (yes), you can do that in C or pretty much in any language. The next step is to mix functional, procedural, and OO styles all in one, which sounds goofy -- but it's kind of cool at the same time. Anyhow, go forth, and take the plunge. The water's fine. (Just beware the alligators -- such as folks who profess fancy "design patterns" and don't have enough common sense to keep things simple when they can be simple).

With that in mind, it depends on what you're using the information *for*. For example, if you only need to process the color information for everything at once, using $color{'car'} and $color{'bike'} make perfect sense.

On the other hand, if you needed to keep the different attributes of an item together (for example, for storage to a file on disk), you might prefer to do this:

$car = { wheels => 4, doors => 4, color => 'blue', trans => 'auto' };
$bike = { wheels => 2, color => 'red',  };
[download]

$"=$,,$_=q>|\p4<6 8p<M/_|<('=>
.q>.<4-KI<l|2$<6%s!<qn#F<>;$,
.=pack'N*',"@{[unpack'C*',$_]
}"for split/</;$_=$,,y[A-Z a-z]
         {}cd;print lc
[download]

my %vehicles = (
  Car=>{
    Wheels=>4,
    Doors=>4,
    Color=>"Blue",
  },
  Bike=>{
    Wheels=>2,
    Color=>"Red",
   }
);

# work with the attributes
while (my($vehicle,$attributes)=each(%vehicles)){
   print "Let me tell you about a $vehicle\n";
   if(my $color = $attributes->{Color}){
     print "A $vehicle is $color\n";
   }
   if(my $wheels = $attributes->{Wheels}){
     print "A $vehicle has $wheels wheels\n";
   }
}
[download]

I can highly recommand YAML for storing this kind of information.

I use it to store configuration information for my web application, and it's lightweight and very flexible.

Here's nother vote for YAML. In fact, if this is a strictly Perl application with no interop issues, you're almost certain to be better off with YAML than XML. Hands down.

Short Answer

You can use references to store any concievable kind of data structure in perl.

### INIT pragma
    use strict;
    use warnings;

### INIT vars
    my  $data_root          = {};
        $data_root->{car}   = {
            wheels  => 4,
            doors   => 4,
            color   => 'blue',
        };

        $data_root->{bike}   = {
            wheels  => 2,
            doors   => undef,
            color   => 'blue',
        };

### DISPLAY
    print $data_root->{car}{color};
    print "\n---------------------\n";

    print $data_root->{bike}{color};
    print "\n---------------------\n";

    print $data_root->{$_}{wheels},"wheels "foreach(keys %{$data_root}
+);
    print "\n---------------------\n";
[download]

Long Answer: what is your goal

Am I treading so close to OOP that I just need to take the plunge now?

OOP may not even be relevant if you are simply looking for a way to store some text data.

See what else is already out there

You can always search on CPAN, you may find something that already fits the bill perfectly. Also, by examining someone else's approach to your goal, you will discover answers to question you hadn't even considered yet. All in all, it is a great way to learn new stuff.

OO - as other have said... 'it depends'. I find the question a little unclear, you have items with attributes...

Car
   Wheels=4
   Doors=4
   Color=Blue
Bike
   Wheels=2
   Color=Red
[download]

my %item = (
  Car => {
   Wheels => 4,
   Doors  => 4,
   Color  => 'Blue',
  },
  Bike => {
   Wheels => 2,
   Color => 'Red'
  },
 );
[download]

so how exactly do you want to use $Item? Do you just want to store the details somewhere? or do you want attribute indexes...

my %item = (
  Car => {
   Wheels => 4,
   Doors  => 4,
   Color  => 'Blue',
  },
  Bike => {
   Wheels => 2,
   Color => 'Red'
  },
  Moped => {
   Wheels => 2,
   Color => 'Blue'
  },
 );

# build an index by attribute to item names...
my %attr;
for my $name ( keys %item ) {
  for my $token ( keys %{$item{$name}} ) {
    $attr{$token}{$item{$name}{$token}} ||= [];
    push @{$attr{$token}{$item{$name}{$token}}}, $name;
  }
}

print "Blue things: @{$attr{Color}{Blue}}\n";
[download]

I haven't figured out OOP yet so, maybe someone else can enlighten us both.

It might help to know more about what you're trying to do with this information. Why can't you just store it in a database?

• How big is the final dataset going to be?
• How many users will be accessing it simlutaneously?
• Is it readonly or read/write?
• What kind of queries would you want to do?
• Will it be stored in the program or externally?

• AoH in the program
• flat text file
• XML
• use DBD::Sprite
• SQLite

If you're just storing data, use a Hash of Hashes (countles examples above).

If your data should be intelligent, use Objects. Consider and example similar to that in perltoot:

You run a business, you employ people (class 'Employee'). They all do different things, they all get paid different amounts and all work different hours. So, in procedural programming we'd have to know all this and branch around the place like crazy. With OO, it's all under the bonnet and we dont need to touch anything:

   $roger = new Employee::Casual( rate => 14.00 );
   $sally = new Employee::FullTime( salary => 50_000 );
   $mark  = new Employee::FullTime( wage => 12.00 );

   $roger->add_hours( 8 ); # worked 8 hours
   $sally->add_hours( 8 ); # worked 8 hours
   $mark->add_hours( 8 ); # worked 8 hours

   # Now pay them
   $roger->write_check(); # 14 * 8  =  $112.00
   $sally->write_check(); # $0.00 - nothing due to a full timer until 
+fortnight is accounted for
   $mark->write_check(); # $0.00 - same here

   # add another 11 days
   # ... same as above, 11 times ...

   # then on day 13, it's a long day
   $roger->add_hours( 10 ); # worked 10 hours
   $sally->add_hours( 10 ); # worked 10 hours
   $mark->add_hours( 10 ); # worked 10 hours

   # So then they take day 14 off
   $roger->sick_leave( 8 ); # 8 hours
   $sally->sick_leave( 8 );  # 8 hours
   $mark->sick_leave( 8 ); # 8 hours

   # and get a work log:
   $roger->write_check(); 
      # 11 days * 8 hours + 1 day * 10 hours = 98 hours @ $14.00 = $13
+72 
      # (no sick pay for casuals and we've already paid him for day 1)
   $sally->write_check(); 
      # 14 days @ ($50000 / 365 days)  = $1917
      # (no overtime for sallary earners)
   $mark->write_check(); 
      # 12 days * 8 hours + 1 day * 10 hours = 106 hours @ $12.00 = $1
+272

   # get entitlements
   $roger->leave_entitlements(); # {sick_leave => 0, annual_leave => 0
+} - none for the casual
   $sally->leave_entitlements(); #  {sick_leave => 56, annual_leave =>
+ 8.6}
   $mark->leave_entitlements(); #  {sick_leave => 56, annual_leave => 
+8.6}
[download]

To learn how to do that, read perltoot. It's not only a good tutorial, it's an easy read and you'll come away having learned something about perl that you didn't know before. Plus, learning OO is very PerlMonk.

bless($me, $ISA[0]) for $i (sin($have));
[download]

<car>
   <wheels count="4" />
   <doors count="4" />
   <color>Blue</color>
</car>
[download]

Why not XML

Lots of reasons.

• He'd have to encode it and decode it.
• He's probably not sending information between machines or processes yet. He may never do that.
• You can add data to hashes too.
• It's more complex to retrieve data from XML.
• You'll have to add XML processing modules to the script. That's fine if you need it, but why?

Perl has built-in data structures that do the job perfectly well; using XML would mean that a module has to translate XML to and from those very same data structures. Why not skip a step?

Update: Re-reading the question, I can understand reading it as asking for a storage mechanism. XML's not bad in that case. I prefer YAML, but XML's workable.

Why Not do both XML and HOH? Try: Config::General Write your HOH as XML, and with a few lines:


  use Config::General;
  my %CF = ParseConfig("./config.dat");
[download]

turn it into HOH in your code.

The module lets you write out hashes as files too.

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

Update:

This was in response to chromatic above. User error hit reply to the wrong node.

I was going to reply until I saw your update and then didn't and now I am again anyway. My point was soley based on a storage mechanism. I agree with all your points and one of the problems I have with XML is the complexity of retrieving data from it; though good schemas and document control can make this less of a task.

I think XML as a storage mechanism has been a hard road for me personally, but having to work with varied systems recently I have found that the intial design and implementation hurdles are worth the extra effort. You will always find the data you used in an application today required by a different application tomorrow, and XML is the closest I have seen for a "Universal Adapter" or whatever the funky sputnik looking orb is in the IBM advert.

"No matter where you go, there you are." BB

This is a particularly good solution if you require persistence. But then, depending on the amount of data and number of objects to be described, you may wish to go with a relational database.