![](/static/66c60d9f/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/8140dda6-9512-4297-ac17-d303638c90a6.png)
Depending on the use-case it maybe should. On the other hand, some things are better left to library implementations rather than custom regex, e.g. email validation
Rust dev, I enjoy reading and playing games, I also usually like to spend time with friends.
You can reach me on mastodon @[email protected] or telegram @sukhmel@tg
Depending on the use-case it maybe should. On the other hand, some things are better left to library implementations rather than custom regex, e.g. email validation
And tuples should have the same types inside. And dictionary keys should have the same type as that dictionary’s values 😈
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
Especially when the “hybrid” model involves more days in office than at home.
Wdym “especially”, of course it does /s but not really
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
That’s okay with me, but is there at least one meeting that requires me? Only having managers in the office could allow one to have an office ten times smaller, and no other people are needed there anyway (or live in a thousand miles radius from the office, since all the managers live in the costly city in the costly state, and the most of others are not even in the States)
Makes me think that with the hybrid they expect to have the best of both worlds, while in fact it will likely be the opposite.
Besides, with a mandatory fixed amount of days per quarter it gets soooo bullshit, it’s not hybrid it’s just barely glorified office work
I’m sure they don’t even understand that it was a discrimination, judging by the fact that they went on and left a lot of evidence of their stupidity
Probably, because in production there are really few things that are best done with regex. Most use I had for regex in production is filling in data from user-provided files with specifically crafted names, and even there there was some guesswork because of errors in naming, and the same thing may have been achieved without regex by splitting and/or iterating