Subscribe to feed Recent Actions from tinita

  • perlancar commented on Introducing IOD file format

    I have. I guess TOML is okay for configuration format too, although it diverges quite a bit from INI. My goal with IOD is to be compatible enough with INI, to be interchangeble enough. Also, I'm not seeing a TOML round-trip parser yet, something which I intend to create for IOD.

  • KENTNL commented on Introducing IOD file format

    > In IOD you can also use this syntax:
    > [section]
    > fruits = ["apple","orange","avocado"]

    But does this not simply re-expose the problem tinita was complaining about?

    It forces the consuming code to determine on a case-by-case basis whether it supports an array, and subsequently requires a lot of boiler plate code to automatically switch between single, and multiple values.

  • Toby Inkster commented on Introducing IOD file format

    It doesn't seem quite the same. In a traditional INI file:


    "bar" is an array, but is "foo" a simple string, or is it an array with just one element? The INI parser will probably treat it as a simple string. If the application wants "foo" to be an array, it needs to include code to "promote" a string into a one-element array.

    With IOD, there is at least a way when writing the config file to unambiguously say "this is an array, even if it's only got one element at the moment".

  • perlancar commented on Introducing IOD file format

    Also, note that in the case of "actual data determining your data structure" IOD is not different from YAML which trinita uses: whether a parameter is scalar or array is still determined by the config. Config::MVP is different in that it uses some sort of "outside schema" to specify that a parameter needs to have a certain form/value.

  • Camspi commented on News flash (for me, anyway): git sub-modules - just don't

    I've never used git sub-modules before, but that blog post makes it sound icky.

    Any time I've had to share Perl code between repositories, I've been an advocate of:

    1) putting the shared code in it's own repo,
    2) packaging tagged versions as distributions with a tool like Dist::Zilla, and
    3) incorporating the package into the consuming repos as I would any other third party dependency.

    If the above steps haven't been possible, it was usually because the design of the shared code was messily coupled to the consuming application and either needed to be refac…

Subscribe to feed Responses to Comments from tinita

About is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.