Hacker Newsnew | past | comments | ask | show | jobs | submit | awwright's commentslogin

Isn't that itself just a variation on the ini syntax, sort of made concrete by PHP, itself adapted from DOS? https://www.php.net/parse_ini_file


Yes. I think this also supports my case.

For me, it was obvious to use `parse_ini_file` because it greatly improved performance (I didn't had to parse it by hand) and familiarity (PHP users already know ini).

On the other hand, there is no reason for toml to have chosen ini. Almost no other language had efficient ini parsers at the time, or any culture related to ini files whatsoever. It sounds like a strange choice outside the PHP context.


Python’s built in ConfigParser has an ini like syntax and was widely used.


Fair point. It would have made sense from a python perspective also.


I think what you're getting hung up on is that JSON does not use IEEE floating point math. If your implementation or environment stores parsed numbers as an IEEE floating point, that's a limitation the implementation has to disclose or work around in some fashion, but it's not a limitation of JSON or JSON Schema as such.


The behavior is perfectly well defined... there's no special cases for integers vs. rational numbers, they're all the same.

For example, given multipleOf: 0.3, and an input of 0.9, 0.9/0.3 is 3, which is an integer, so would be accepted. A value of 0.8 would be rejected.


0.3 is not the same thing as 3/10 in ieee754, neither is 0.1 the same as 1/10.


This is wrong. All numbers in JSON are arbitrary-precision base-10 decimal numbers.


No they aren't. The JSON spec says implementation is up to the engine and de facto JSON numbers are parsed as ieee754 on just about every platform I can think of.


It does. In fact, not only does JSON support big ints, but it supports arbitrary-precision base-10 decimal numbers.

Whether your JSON parser will preserve the precision correctly is another story. For JavaScript/ECMAScript, you'll need to use a library.


Two corrections:

(1) This is a good overview, but conservatives don't believe in the status quo for the status quo's sake. They believe that our traditions are highly optimized, essential components to living a fulfilling life. We don't even know why many of the rules even exist, the exact problem they solve has long been forgotten to history; so we should be careful when changing these rules.

There is an element of caring for your long-term health as well as the larger society, and raising the next generation of humans, which most everyone agrees with in some form (even libertarians argue that absolute individual liberty is what produces the best outcome for society). This not necessarily make you a collectivist, in the way that progressives push for labor unions, economic planning, and intersectionality.

What you're missing is a description of when conservatives support use of force to promote social values. Modern American conservatives think that rights come with responsibilities, that neither unfettered libertinism nor enforcement of responsibility with police power is legitimate.

(2) Clarence Thomas has never spoken from the bench about what laws the state ought to pass, he is careful to emphasize he is not a lawmaker and that is not his job. When he dissents in Obergefell and other cases that rely on "substantive" due process, it's because i legal rationale invented to uphold slavery in Dred Scott v. Sandford.


It seems like there's two slight misunderstandings:

> "oneOf": [ {"type": "number"}, {"type": "number"} ]

> { "oneOf": [ {"minimum": 0, "maximum": 10}, {"minimum": 5, "maximum": 20} ] }

"oneOf" requires exactly one match (hence the name), typically you want to use "anyOf" or "allOf". And there's no benefit in putting two identical values inside them.

> { "type": ["object", "array", "null"], "not": {} }

> { "allOf": [ { "type": "object", "properties": { "a": {"type": "string"}, "b": {"type": "integer"} } }], "additionalProperties": false }

JSON Schema is merely a list of assertions. Some test the type of the value (that's the "type" keyword), others test the value ranges within a single type. This way, you can allow values to be one of multiple types, e.g.: {type:["string","object"], minLength:1} means "Value must be a string or object; and if it's a string, it must have at least one character."

Some of the assertions are spread across multiple keywords, "additionalProperties" depends on "properties", for example. So, {additionalProperties:false} means: if value is an object, then only an empty object is permitted.

Some implementations can tell you if you're trying to do nonsensical things (like test the maximum length of a value that's only allowed to be a boolean), but that's up to the implementation to test for.


Yes, it's my mistake using JSON Schema for something it does not suppose to. Analyzing schema from user input is very difficult if "type" keyword is not required (I actually had read the GH's issue about it). IMHO, JSON is already verbose, no need to make it concise, requiring "type" make it a lot simpler. I'd also prefer not to allow multiple type on "type" keyword.

The fact that the spec is too flexible that allow users to write all nonsensical things, and so sensible things that might have hole on assertions.

I understand all your explanation and thanks for creating a new account to do this, appreciated!


How is that simple? What does "status" mean? I'm personally familiar with the word "status"—but whatever that property is, I'd have to re-implement it in my user agent, which seems like a waste because my user agent already understands HTTP status codes. How is it simple to have to look at and interpret two different "status" fields? (And that's just the first property!)

What part of the article is verbose? What's wrong with verbose?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: