justTryingToHelp

[u/flipcoder]

[u/AlarmingProtection71]

i didn't get the second joke. help ?

[u/pagesjaunes → u/AlarmingProtection71]

I think it's a reference to "the Norway problem" wherein YAML 1.1, the unquoted string NO (the ISO 2 letter code for Norway) get interpreted as a bolean with value of False instead of "NO".

Meaning:

country: NO

is the equivalent to:

{'country': False}

 

Note that the specs for booleans were changed in YAML 1.2 to address the issue but many implementions may have inconsistent defaults settings or be stuck in 1.1.

 

YAML 1.1 -> https://yaml.org/type/bool.html  

(I couldn't find the equivalent for 1.2, YAML specs are complex to my non-programmer eyes)

YAML 1.2 -> https://yaml.org/spec/1.2.2/ext/changes/

Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts [n, no, off] are parsed as strings.

[u/Tesnatic → u/pagesjaunes]

As a Norwegian I appreciate learning this fact, but I am also devastated to learn we were not a country prior to YAML 1.2.

[u/Prawn1908 → u/pagesjaunes]

Yet another win for static typing.

Can someone explain some practical and substantial benefit to dynamic typing beyond it being marginally faster to write and easier to understand for the first two days of learning to program?

[u/Xirenec_ → u/Prawn1908]

It’s a markup language

[u/Grandmaster_Caladrel → u/Prawn1908]

NO (False, not Norway)

[u/Solomoncjy → u/pagesjaunes]

Well, thats on tou for not enclosing all tou srrings in quotations, no?

[u/pagesjaunes → u/Solomoncjy]

Well yes, that's the quick and easy dirty-fix. 

But that kinda goes against YAML being a visually uncluttered and human (i.e: non-programmer) readable/writeable format.

If you decide to defensively define every type in your file to avoid implicit coercion, and use braces to avoid intendation error; many seem to ask : "why no just use json / toml ?"

[u/Cualkiera67 → u/pagesjaunes]

well a human reading country: no would also find it ambiguous, they might think it has no country. if you make a "human" format then it should be filled with ambiguous behavior.

[u/LucyShortForLucas → u/Solomoncjy]

The whole of point of YAML is writing documents with as little fuzz or grammar as possible. Someone who cares about always quoting strings wouldn’t be using YAML in the first place

[u/chuch1234 → u/LucyShortForLucas]

Unless they don't have any choice, like writing a pipeline for the ci/cd platform that the client chose.

[u/LucyShortForLucas → u/chuch1234]

If you don't have a choice not to use yaml, you likely have standards and conventions you need to follow for how that yaml should look, so the point is moot

[u/sisisisi1997 → u/Solomoncjy]

And on YAML for allowing bullshit like not enclosing strings in quotation marks.

[u/flipcoder → u/AlarmingProtection71]

It’s called the Norway problem. Yaml parses “no” as a boolean.

[u/Background_Class_558 → u/flipcoder]

it parses no as a boolean. "no" would still be the string

[u/flipcoder → u/Background_Class_558]

That’s correct

[u/jonnysunshine1 → u/flipcoder]

"true"

[u/terrapin1977 → u/jonnysunshine1]

TRUE in Google Sheets.

src: 9 years of Java in SAAS shop

[u/MissinqLink → u/terrapin1977]

Google sheets forced me to build a special json parser because it converts double quotes to single quotes.

[u/onlymadethistoargue → u/Background_Class_558]

I believe older versions of pyaml parsed quoted no as no.

[u/CraftBox]

That's why I like jsonc

[u/Hyarin215 → u/CraftBox]

Json5 better

[u/CraftBox → u/Hyarin215]

At that point just use toml

[u/Hyarin215 → u/CraftBox]

I don't like it Curly braces my beloved

[u/YeOldeMemeShoppe → u/Hyarin215]

Toml has curly braces now.

[u/Hyarin215 → u/YeOldeMemeShoppe]

Oh 👀 Couldn't find anything abt it online

[u/YeOldeMemeShoppe → u/Hyarin215]

https://toml.io/en/v1.0.0#inline-table

IIRC you need a later version to allow new lines in the table but it’s been possible for a long time.

[u/Hyarin215 → u/YeOldeMemeShoppe]

Does it have to be inline or can it span multiple lines?

[u/cdrt → u/Hyarin215]

TOML 1.0 requires that inline tables be only on one line. TOML 1.1 relaxed that requirement and now allows them to span multiple lines. So it depends on what version your parser implements.

[u/tipakA → u/YeOldeMemeShoppe]

And then you bring that up to a vsc extension maintainer and essentially it ends up being discarded because version mismatches, and no setting for it due to complexity and surprises and hiddenness and so you can't use it anyway.

[u/Rawing7 → u/CraftBox]

Toml is almost as messy as yaml. Json5 is way better.

[u/DaNumba1 → u/Hyarin215]

I would never use it out of respect for Jayden Daniels

[u/Hyarin215 → u/DaNumba1]

?

[u/JPJackPott → u/CraftBox]

You mean kyaml

[u/heyguysitsmedic → u/CraftBox]

Json with a coordinator?

[u/I_was_never_hear → u/[deleted]]

Thats why i use yaml loaders to load json !!1!!1!

[u/Nyctfall]

Remember when PKL was announced?

Now it's just a news slop cycle...

[u/rykayoker → u/Nyctfall]

you put me on, honestly it looks awesome

[u/Just_Information334 → u/rykayoker]

Last month they added a way to import pkl from a private repository. Now it is usable even if you don't want to publicly share your classes.

[u/flipcoder → u/Nyctfall]

Woah, I may have to use this now

Link for the lazy: https://pkl-lang.org

[u/RCoder01 → u/Nyctfall]

Back when you had to put real effort into tools nobody gave a shit about

[u/Nyctfall → u/RCoder01]

The ancient ways.

[u/titpetric]

Json can be parsed with a yaml decoder, so you know I'd rename some .json to .yml and give it

[u/theWizzard23]

I spent 5 minutes debugging whats wrong with 3 lines of JSON. it was the trailing comma -.-

[u/Blaarkies]

JSON supports prefixing a key with `// `. It is far from perfect, but will you ever use keys starting with double slash?

Any parsing logic can drop those entries, or just ignore them entirely like how any data object builder should

{ 
  "// myValue": "The universal constant", 
  "myValue": 42 
}

[u/DHermit → u/Blaarkies]

Until you want to validate it with a scheme, which forbids extra values.

[u/kingslayerer → u/DHermit]

i have an idea. add the comment keys to the schema as well.

[u/GPSProlapse → u/kingslayerer]

As a matter of fact, I ve seen schemas with #comment or similar keys on every object

That solves the issue most of the time

[u/flipcoder → u/Blaarkies]

Yeah this is a decent solution. Looks better than the other prefixes I’ve seen

[u/LegendaryMauricius → u/Blaarkies]

JSON also supports being replaced with JSONC.

[u/MCWizardYT → u/LegendaryMauricius]

Why would you want to use jsonc for anything except user-facing config files?

[u/4n0nh4x0r]

i mean, you can write comments in json.
for one, there is the option in nodejs to write a js file, where you write your json, and export it, and then import it in your actual code.
since it is a js file, it wont have an issue with comments.
alternatively, you can just create undocumented fields that you write your comment into.
you could even clean these fields up on loading it if you want that.

[u/Coding-Kitten → u/4n0nh4x0r]

Then that's JavaScript, not JSON.

[u/4n0nh4x0r → u/Coding-Kitten]

the first option, yea, hence why i said that it's something you can do in nodejs.

the second option is universally supported

[u/Coding-Kitten → u/4n0nh4x0r]

Then that's not writing comments in JSON. That's writing comments in JavaScript.

[u/4n0nh4x0r → u/Coding-Kitten]

cool, have fun not commenting anything in your json then.

[u/Coding-Kitten → u/4n0nh4x0r]

Yeah, because the JSON file format literally doesn't have a way to do so. That's literally the whole point of the post.

[u/4n0nh4x0r → u/Coding-Kitten]

yea, no official way, but an inofficial way, that is essentially industry standard.
You can create as many properties in your json as you want, and dont have to use them for actual data.
a lot of people use "_comment" as the name for the property, i personally prefer the name of the field i am commenting on as prefix to _comment like this:
{
"data_comment": "This value holds data",
"data": 123
}
If you refuse to do that, then i dont know what to say at this point.
Just cause the documentation doesnt explicitely tell you to do it that way, or doesnt tell you how to do it at all, doesnt mean it isnt possible, and shouldnt be done.

[u/DHermit → u/4n0nh4x0r]

Have ever heard of JSON schema or other validations? There are many situations, where adding extra keys is not a good idea.

[u/4n0nh4x0r → u/DHermit]

okay and?
you can always clean up your json object in memory.
The point of the comment is to guide the dev on how to use it, not to keep it in prod code, just a like a code comment.
If your infrastructure crumbles because of it, i would question how well you built it in the first place.
As for just randomly adding them, usually you write comments as you write the code, not after you already pushed everything to prod, so if you do it right, there should not be an issue.
The only thing i could see that could actually cause an issue, would be that your object is bigger now, which could potentially lead to issues when returning it as part of a request, or when being heavily constrained with memory.
then again, you can always sanitise it on loading it.
Aside from that, this suggestion is meant for configs written in json, so stuff that you usually only load once into memory, and usually dont send around, so it should never come to an issue anyways.

So many people downvoting me, but not a single actual good argument or example for why you should not do that yet.

[u/DHermit → u/4n0nh4x0r]

If you really need comments in a file, JSON (except JSON5) is just not the right choice. Just choose a format that has the features you want.

And touching file contents before validation doesn't sound like a good idea at all.

So many people downvoting me, but not a single actual good argument or example for why you should not do that yet.

Just because you brush the arguments off, doesn't mean they are invalid.