Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That’s very dense. Putting a new key/value pair in the hash at the same time as extracting it from the self-same hash is a real stumbler. The other statement is a lot less terrible, but reading a multiply nested multi-line expression is never fun. And it’s all in situ modifications. And all on $_. Just using an actual variable name and linearising things a bit helps a heap:

    foreach ( @$elements ) {
        my $elt = Array::AsHash->new( { array => [ %$_ ] } );

        my @kv = $

    • I agree your code is clearer and it's certainly something I need to seriously rethink. It's part of Bermuda and I've been struggling with the YAML and JSON implementation. Basically, I've found that since we (the BBC) primarily need this for our XML representation, I've focused much energy on this. We'd like to take the same island file which maps an object to XML and use the same island to produce multiple serializations in XML, YAML, and JSON. Unfortunately, it's not extremely clear how to transform X

      • A general serialisation of XML to JSON is a fool’s errand. It has come up numerous times in the Atom camp, and every time the discussion goes nowhere. You can of course define a full mapping of XML to JSON, but the result is nothing at all like how you’d express the same data if you were writing JSON by hand – you get one or two extra layers of indirection along every step of the way.

        The only approach that yields usable results is to define a first-class serialisation of your domain model to JSON.

        If you want specify both the XML and the JSON serialisation of a model using the same schema, then you’ll have to impose restrictions on the models your schema can express so that both serialisations are reduced to a common denominator. Then you won’t be able to specify arbitrary XML or JSON grammars with your schema language. (Then again, I already doubt you can handle all of XML. Processing instructions, anyone?)

        But you can’t have it both ways, I’m afraid. That’s just how it is.