[lazcorp]I'm using it as it's a dependency of indieweb/mention-client-php - been using it for about 2 years, but now PHP8.4 is demanding things that didn't exist in PHP 5.6.0
[tantek]I believe we support back to PHP5.x in order to support a very wide variety of clients, including WordPress plugins which themselves want to support WordPress running on old versions of PHP
[lazcorp]In PHP 8.4 implicitly marking parameters as nullable is deprecated - they have to be explicitly marked as null. So "function parse($url = null)" needs to be "function parse(string|null $url = null)" in php8.4.x
gRegorIf it's possible to silence deprecated warnings in just php-mf2, that might be an option. Though I'm not sure that's possible. And we'd still need to stay on top of those in dev to fix them for future releases.
gRegorThere are ways around the nullable type thing, but we'd need to refactor some of the code to ensure methods don't sometimes get called with a null and sometimes with another type
jkingweb@[lazcorp] What you wrong is not quite true. foo($bar = null) is fine. foo(Baz $bar = null) is not. Removing type hints is a viable fix is one wishes to retain pre-7.1 compatibility. Those using strict mode in a 7.0 code base are out of luck, but there are probably vanishingly few of those who can't bump their requirement to 7.1.
[lazcorp]So it sounds like the code in mf2 - "public function parse($convertClassic = true, DOMElement $context = null) {}" breaks in php 8.4.5 _because_ it has the "DOMElement" type
[tantek]every time I run into a scripting language error / warning about types, my response is ok, you get to be a string, and you get to be a string, and yes you also get to be a string
[lazcorp]It might be worth just omitting the type declarations in the next PHP 5.x+ release - just to ensure compatibility with PHP 8.4 while we decide on the future direction?