in reply to When hashes aren't enough

Why not XML 

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

[download]
This type of problem seems ready for XML especially if other levels are added later like make, model, year, standard, custom, etc. Also you will keep the description of the multiple attributes in your schema allowing the data to be parsed by more than just one specialised app.
"No matter where you go, there you are." BB

Replies are listed 'Best First'.
Re: Re: When hashes aren't enough
by chromatic (Archbishop) on May 25, 2004 at 16:43 UTC
    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.

[reply]
      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

[reply]
[d/l]

        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

[reply]
[d/l]

      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
[reply]
Re: Re: When hashes aren't enough
by orderthruchaos (Scribe) on May 25, 2004 at 16:48 UTC
    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.
[reply]

In Section Seekers of Perl Wisdom