@Crell@ilutov Nothing forbids a method to call a static method of another class that would hold that static counter anyway. So I don't see a way to close such loophole entirely anyway.
This Friday, February 16, 2024, from 10:00 to 12:00 (Europe/Berlin), I will explain the motivation behind the most important changes in #PHPUnit 11 and demonstrate them with live coding. We will cover new features as well as migrating from PHPUnit 10 to PHPUnit 11.
This online event is part of thePHP.cc's education flatrate, but is free and open to all.
Would you like to attend? Just send me an e-mail with the subject "PHPUnit 11 Live Demonstration" to sebastian@thephp.cc.
@sebastian too bad. If the announced times are in the CET timezone, I'll be in a meeting so unable to follow it live. Will there be a blog post describing those motivation in the future ?
Played a bit with statistics this week: The average age of PHP code lines in #symfony
75% of the lines are edited within the past 4 years. That's pretty amazing for a codebase that is 15 years old!
Also interesting to see some components that were more or less feature complete from the start (Mime, RateLimiter, etc.) and needed very few changes after their release.
@wouterj regarding the ratio of lines edited recently, I suspect that it is also related to the effort of modernizing types (and coding standards) that has been done in the last 2 years. I would be curious to see that percentage when taking the 5.0.0 codebase as input of the analysis instead.
@chris We moved away from bundles for projects because it simplified things as those bundles were often not reusable anyway (nor decoupled when having multiple ones). But bundles still exist in Symfony and are the way to share things (project-level code can customize the kernel directly, but that's not composable without bundles)
@bagder I think this came a lot at a time where PHP on Windows was not able to use the CA store automatically, forcing either to disable verification or to provide the trusted CA certificates in the app. And then, this was kept around even after PHP 5.6 fixed this.
@Crell My issue with this SQL file defining the DB structure is that this is now what you would run in your DB as you cannot recreate it from scratch: you need to migrate it from a previous version. So I'd rather make PHP canonical and generate the SQL side (but generating incremental migrations for SQL, not a file starting from scratch) @kboyd
@Crell Your previous comment seemed to say that you wanted one .sql file that gets imported to the DB. But this cannot be imported to the prod DB as it cannot both describe your whole setup and apply only a diff (unless it does crazy introspection inline but this is not something I want to write then) @kboyd
@Crell@kboyd To create the prod DB (and then actually also using it for other envs including local so that it tests it), I'd rather have something like doctrine/migrations which defines incremental steps to be applied one after the other (and some places remembering which steps have already been applied)
@Crell@kboyd But then, if those migrations are the canonical source for the structure of the DB and generated PHP code, it becomes hard to see at a glance how the current structure looks like
#PHP yield keyword allows anything as key, and that is transmitted to the calling foreach() command. So, you can have arrays or closures as keys, or worse.
@b0rk to squash commits, I generally prefer doing git rebase main --keep-base instead of counting how many commits I need to go back with ^. It is a lot easier.
I understand #git just fine and like it the best of any VCS I've used. Am I weird?
If people are having trouble learning it, it sounds like the problem is the training materials. What training materials did you use that were inadequate?
#PHPUnit 9 says to stop using assertObjectHasAttribute() in favor of assertObjectHasProperty(). But the latter doesn't exist in PHPUnit 9, only in PHPUnit 10.
Am I missing something obvious? Because that's not how deprecation warnings are supposed to work... #PHP
If you voted against the Interface Default Methods RFC for #PHP, please take a moment to read some of the most recent mailing list replies, starting with @Crell’s here: https://externals.io/message/120725#120798
I agree this feature goes against a lot of what I’ve learned as “best practices,” but I did a lot of introspection on this and decided that this feature is good for the future of the PHP language. It unlocks a lot of potential.
