625
TOML (europe.pub)
submitted 7 months ago by to c/programmer_humor@programming.dev
159 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 38 points 7 months ago (10 children)

The json spec is not versioned. There were two changes to it in 2005 (the removal of comments

See, this is why we can't have nice things.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 18 points 7 months ago (9 children)

    I can kind of understand it after having to work with an XML file where users encoded data into comments for no good reason. But yeah, it does make JSON awkward for lots of potential use-cases.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 8 points 7 months ago (4 children)

    Hm? Comments are not data.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 9 points 7 months ago

    They're not supposed to contain data, but some parsers will allow you to access what's written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:

    <!--
    Host: toaster,
    Location: moon,
-->
<data>Actual XML follows...</data>

    My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 6 points 7 months ago (2 children)

    They are useful metadata important to the longterm lifespan of the codebase

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 7 points 7 months ago (1 child)

    That's why they make sense in code and config files. JSON is neither, despite the insistence of far too many people to write configuration in it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 7 months ago*

    In an ideal world, yes. In a locked down world where you have access only to 1/4 the codebase or your job is more ontology-focused, all you have access to might be the JSON. Leaving a comment or two about why a particular value or hierarchy is as it is is sometimes more clear than writing up a seperate README that no one will read

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 7 months ago (2 children)

    Anything can be abused. That’s not a legitimate reason to take away perfectly reasonable features. Looking at you, Java (unsigned integers).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 7 months ago (1 child)

    Well, I assume they had other concerns, too. For example, it adds a bunch of complexity for reformatting a JSON from single-line to pretty-print, if comments can appear in there. I'm certainly not saying that I'm always best friends with the decision to remove comments, just that I can somewhat understand it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 7 months ago

    Their stated justification is that people would abuse comments, using them to carry semantic or syntactic information. That’s a shit justification IMO.

    As far as the additional complexity that comments bring, I understand that from a technical perspective but from an engineering-for-real-humans-in-the-real-world perspective that’s the kind of thing you just have to deal with if you want to design a good format.

  • permalink
  • fedilink
  • source
  • parent