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

Why overkill and do more work than you need to? As you say, the module lets you write out hashes to files too. If you ever need to represent it as anything other than hashes, you can do that work then. By the time you need it, you may even want to use another format. Writing the data as hashes is no extra work (less, rather) than writing the data as XML.

ihb

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