Juniper / libxo

The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.
http://juniper.github.io/libxo/libxo-manual.html
BSD 2-Clause "Simplified" License
321 stars 48 forks source link

"xo" needs a means of handling lists and instances #61

Closed philshafer closed 5 years ago

philshafer commented 6 years ago

See https://lists.freebsd.org/pipermail/freebsd-hackers/2018-September/053304.html

3) "machines" is an object, which erroneously contains 2 "machine" keys

This is a bug. "xo" lacks a means of knowing that an object is a list. One might expect that labeling "name as a key would perform this, but it doesn't, and it's not clear that this is enough information. Since "xo" is stateless, it cannot really handle that "--wrapper machine" applies only to the first item. It would have to know not to generate the closing "}" for machine, but it's stateless, so I'd need a means of telling it that.

In C code, we have "xo_open_list" and "xo_open_instance", like:

https://libxo.readthedocs.io/en/latest/api.html?highlight=xo_open_instance#lists-and-insta nces

But with "xo" I don't have lists and instances. I'll need to find a means of adding these, though that would make "xo" more cumbersome and it would lack the FSM (and the stack) that catches missing calls in libxo.

    xo $opts --open-list machine
    for name in red green blue; do
        xo $opts --open-instance machine
        xo $opts "Machine {k:name} has {:memory}\n" $name `get-mem ~name`
        xo $opts --close-instance machine
    done
    xo $opts --close-list machine

Which is very exact but less that beautiful.

Thanks, Phil

philshafer commented 5 years ago

Fixed in develop branch