![](https://programming.dev/pictrs/image/a491cc5f-fa6b-402c-af4c-7f6ae4c276da.webp)
![](https://lemmy.ml/pictrs/image/c0ed0a36-2496-4b4d-ac77-7d2fd7f2b5b7.png)
God I hate it
Professional developer and amateur gardener located near Atlanta, GA in the USA.
God I hate it
Make sure to make ample use of mixed content elements.
<statement><var>bar</var> = <int>0</int></statement>
And then another, where a trans woman is called “spam.”
Pretty clear they meant the PR was spam, not the person.
And then another, where a trans woman is called “spam.”
With comments like this it’s clear the author is just overreacting. They were clearly calling the PR spam, not the person. (And this is coming from someone who was definitely angry with them for denying the original PRs and stuff.)
Then the problem is the schema being under specified. Take the classic pet store example. It says that the I’d is int64. https://petstore3.swagger.io/#/store/placeOrder
If some API is so underspecified that it just says “number” then I’d say the schema is wrong. If your JSON parser has no way of passing numbers as arbitrary length number types (like BigDecimal in Java) then that’s a problem with your parser.
I don’t think the truly truly extreme edge case of things like C not technically being able to simulate a truly infinite tape in a Turing machine is the sort of thing we need to worry about. I’m sure if the JSON object you’re parsing is some astronomically large series of nested objects that specifications might begin to fall apart too (things like the maximum amount of memory any specific processor can have being a finite amount), but that doesn’t mean the format is wrong.
And simply choosing to “use string instead” won’t solve any of these crazy hypotheticals.
Open washing, which is to say the proliferation of licenses that look FOSS if you squint but don’t work if you look closer, and practices related to these licenses. Here we have big players like Elastic, Redis, MongoDB, and numerous smaller cases as well. The practice of building off of the lavish advantages of being in the FOSS ecosystem, then pulling the rug and seeking exclusive commercial monopolization of the end result.
Someone help me understand why this is a problem. I am willing to accept that I’m missing something. As I see it,
So… My question is, what’s different about SSPL?
and a pronoun selector.
Which is sort of silly because Discord profiles themselves have a place for pronouns and you can customize them per server (without needing to pay for anything unlike other per-server profile customizations). So, if anything, that shows that these servers are trying to be inclusive.
This is what I was getting at here https://programming.dev/comment/10849419 (although I had a typo and said big instead of bug). The problem is with the parser in those circumstances, not the serialization format or language.
Can you give a specific example? Might help me understand your point.
I (think, at least) the point they’re making is that unless the API contract specifically differentiates between “present and null” and “absent” then there is no difference. (Specifically for field values.)
Just what every programming language needs, not one, but two types of null! Because nobody ever said one type was difficult enough.
If I see any of you make this distinction matter for anything other than “PUT vs. PATCH” semantics I’m going to be very angry.
I’m not following your point so I think I might be misunderstanding it. If the types of numbers you want to express are literally incapable of being expressed using JSON numbers then yes, you should absolutely use string (or maybe even an object of multiple fields).
For the love of all things pure, holy, and just, please do not use YAML in your APIs…
It’s entirely disingenuous because who the hell is throwing JSON into YAML without converting it? Oh wow, I changed the file extension and it still works. I’m so glad we changed to YAML!
Unless you’re dealing with some insanely flexible schema, you should be able to know what kind of number (int, double, and so on) a field should contain when deserializing a number field in JSON. Using a string does not provide any benefits here unless there’s some big in your deserialzation process.
Should be like 0o777
to mimic hex 0xFF
Do you actually use them?
The generic name I’m complaining about is “conventional commits”, not “fix” and “feat”
Regardless, times I’ve tried to get access to work stuff on my phone I stopped because I had to agree to let my entire device be remotely wiped if they chose to. I had absolutely zero faith that they wouldn’t accidentally do it as a matter of procedure if/when I left the company so I didn’t do it.
Don’t apologize, it’s beautiful in its horribleness