the simple Store/Retrieve is all I needed. -- Ah, the simple store/retrieve is not so simple.
My personal preference between YAML, Storable, and JSON is YAML. As for version of YAML, I'm not fussy so I use YAML::Any. That way I can use whatever YAML (XS, Old, other) that has been installed on the host system.
YAML handles a much wider range of data structures than JSON, as wide as Storable, and it won't blow up on you if you just happen to have a circularity in your data.
I prefer YAML over Storable, because YAML is human readable and machine/Perl version independent. The main issue with Storable is that the data is dumped exactly as Perl stores it in C, which means that it is machine specific and possibly Perl release specific. You can't assume that a file you dump on your machine will load properly on another machine.
Since Storable dumps in a format efficient for the computer and not a person, its output is not at all easy to inspect, if you are trying to figure out what went wrong. Finally, it is a bit fussy to test dumped data (did I get what I expected?) in an automated fashion because small details about the way a variable is handled during the life of the program (namely whether it was used as a string, number or both) can change the way a number is dumped.
Since JSON is also human readable, JSON is often pushed as the faster, more "hip" substitute for YAML, but there are some limitations that really make it only suitable for very simple kinds of data. Neither Storable or YAML face any of these limitations.
JSON blows up if there is a circular chain of references in the data it is trying to dump (or did as of June 2009). Both Storable and YAML handle circularities with grace.
There is no way to preserve the fact that two different hash keys store the same reference. Or more generally, it can't dump any sort of network graph.
When you dump the hash you will dump the data attached to the reference twice. When you reload the hash, the keys will point to distinct objects. This can be a serious problem for any data structure or algorithm that is relying on reference equality. The algorithm will work one way before dumping and another way after dumping and reloading. Both YAML and Storable handle network graphs with grace.
Dumping objects is a pain. JSON can do it, but you have to have a TO_JSON method for each object you want to dump. Alternatively you can run JSON with the -convert_bless_universally argument, define a generic object converter and name it UNIVERSAL::TO_JSON. Again YAML and Storable handle this task with ease.
Loading objects back in is even worse. There is no syntax to store the class of a dumped bless reference. All you have is the raw hash or array. If you are set on reloading your data back in as objects, your TO_JSON method will have to come up with some convention for identifying the class and you will have to write a custom loader that knows how to convert the array or hash back into a blessed object. It isn't a big deal to write, but it isn't "out of the box" and any roll-your-own convention can run into problems if the dumped data has to be shared widely at some point. Reloading objects complete with their blessings is built into both Storable and YAML
In reply to Re: Converting from Storable to YAML
by ELISHEVA
in thread Converting from Storable to YAML
by raybies
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |