![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
Not if the new UI consists of a single close button: “make whatever I want”
Rust dev, I enjoy reading and playing games, I also usually like to spend time with friends.
You can reach me on mastodon @sukhmel@mastodon.online or telegram @sukhmel@tg
Not if the new UI consists of a single close button: “make whatever I want”
the guest tells you they want the fluffiest pancace possible, positioned vertically on the plate.
In fact they want four of them, each perpendicular to all othes
This is not completely wrong, though
Also, I like how this problem had a really simple solution all along
There really isn’t anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn’t want to write their code in a robust manner.
Yeah, totally, it’s all those faulty programmers fault. They should’ve written good programmes instead of the bad ones, but they just refuse to listen
Underspecified schema is indeed a problem, but I find it too common to just shrug it off
Also, you’re very right that just using strings will not improve the situation 🤝
Well, one of the most widely used that allows to do low-level stuff. The most widely used one is by far JavaScript but good luck making an OS or a device driver with it
I disagree a bit in that the schema often doesn’t specify limits and operates in JSON standard’s terms, it will say that you should get/send a number, but will not usually say at what point will it break.
This is the opposite of what C language does, being so specific that it is not even turing complete (in a theoretical sense, it is practically)
I am not sure what could be the example, my point was that the spec and the RFC are very abstract and never mention any limitations on the number content. Of course the implementations in the language will be more limited than that, and if limitations are different, it will create dissimilar experience for the user, like this: Why does JSON.parse corrupt large numbers and how to solve this
The point is that everything is expressable as JSON numbers, it’s when those numbers are read by JS there’s an issue
No problem with strings in JSON, until some smart developer you get JSONs from decides to interchangeably use String and number, and maybe a boolean (but only false
) to show that the value is not set, and of course null
for a missing value that was supposed to be optional all along but go figure that it was
Well, we don’t, but every electonic tables software out in the wild on the other hand…
Yes, I know that you can force it to become text by prepending '
to the phone, choose an appropriate format for the cells, etc, etc
The point is that this often requires meddling after the phone gets displayed as something like 3e10
I do, but I also don’t think that’s a silver bullet, unfortunately. There’s convenience in code generation and compatibility, at least
Well, Jackson before 2.9 did not differentiate, and although this was more than five years ago now, this is somewhat of a counter example
Also, you sound like serializers are not made by developers
Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching
You didn’t listen when we told you there’s malware in torrents, so we put malware in torrents
This isn’t exactly right, since it can’t be delivered from the original pair of statements
uBlock Origin is also not piracy, but it is the real way to block
That’s deeper than it seems
Yeah, licenses like WTFPL highlight the difference between freedom for the user vs freedom for the developer.
I’m still not sure about which to consider the best license
And tuples should have the same types inside. And dictionary keys should have the same type as that dictionary’s values 😈