As long as optional parameters are placed last, I don't see why not.

PHP8's named parameters lessen the pain of using a function with optional parameters spread around, but I still stick to that rule.

Ok, I understand what you meant, thanks.

Basically, after I’ve read all of that, it’s clear as day that security is not a priority on Testing. And while band-aid solutions do exist, it’s simply not designed to be secure.

Yeah, I wouldn't run it in a production environment.

I remember having some issue like that, but I'm not sure if this was the fix.

Try unchecking "Show desktop notifications when the song changes" on Spotify's settings (right now it's under the Display section).

Makes sense, thanks.

I particularly like the new Mapped Route Parameters.

❌ /show/{id}/

✔ /show/{id:document}/

For multiple entities, it's cleaner and more beginner-friendly than using the #[MapEntity] attribute (which is still an option).

And imo it's a good move to deprecate "not passing the mapping" even for single entities. With the mapping the behaviour is more intuitive and "feels" less magic.

The band played 2 early albums + their latest one in sequence. Listening to whole albums in one go was great for many reasons.

One that is written in C and also has a Python module: https://aubio.org/

May be a coincidence, but it stopped launching for me too. Worked Monday and Tuesday, yesterday I didn't try to play, today it didn't work.

Tried:

• running "verify integrity of game files"
• forcing Proton,
• clearing shader cache
• attempted various launch options, like vulkan, fullscreen, and windowed
• update all flatpaks (since I installed steam through flatpak)
• reboot

Makes sense, thank you for the clarification.

It is also a file browser.

And apparently also supports FTP/SFTP, quite nifty.

My point is, you won't ever try. You'd only use "weak" variables inside the function you're working on.

It's explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it'll return

I like it in modern PHP, it's balanced. As strict or as loose as you need in each context.

Typed function parameters, function returns and object properties.

But otherwise I can make a DateTime object become a string and vice-versa, for example.

I don't know if we're discussing semantics. A performance score is attributed, and before the fix their scores were all 166. It doesn't work, as you said. So the consequence is the preferred core being "random", isn't it?