Weekly update – 29 November 2024?

[ryan]

It’s been a fairly quiet week here at the ProcessWire HQ as it’s a Thanksgiving week where the kids don’t have school, which means less time in the office. This is the time of year when we think about what we’re thankful for, and I’m especially thankful for all of you and the ProcessWire community. 

Even with the holiday week, work continues on our next main/master version of ProcessWire. This week Bernhard and Adrian identified that ProcessWire doesn’t work well with PHP 8.4 due to some new deprecations introduced by this version of PHP. It’s a technical detail, but PHP 8.4+ wants a question mark before function/method arguments of named types that have a default value of null. So if the function arguments were (PageArray $items = null) PHP 8.4 wants it to be (?PageArray $items = null). 

Why? Who knows, perhaps not even PHP does, as “?” points directly to it being a question, one with no obvious answer. Perhaps it wants to make sure we really meant what we wrote, so the “?” is an “are you sure?”. Without question, the “= null” part is a pretty clear statement about what the intention is, no? I question the question mark, doesn’t this turn arguments into questions? Questionable arguments?

Being so close to a new master/main version, there’s no question that we want to make sure it works with the latest available PHP version, questionable or not. So that meant adding new questions to 72 different core files, which you’ll find on the dev branch this week. There may be more questions yet to answer, but those are the instances I was able to find so far. There’s a tradeoff in that the questions were introduced by PHP 7.1, so it’ll produce a parse error on any prior versions of PHP. Meaning, our minimum required PHP version is now 7.1. Prior to today, it was 7.0 (actually, PW still even worked even on PHP 5.6, not that it matters). Similar questions will have to be added to modules before they are PHP 8.4 compatible to not throw deprecation notices, so I’ll be making some questionable updates to Pro and public modules in the coming weeks as well. Thanks for putting up with all my questions and have a great weekend! Please reply with your questions below. 

[adrian]

Thanks Ryan for your hard work getting things ready for 8.4. 

While I see your frustration with PHP's change here, and appreciate your humorous commentary, I do actually think it makes sense when you consider that null is not a string or an array or some PW object, so there needs to be some way to explicitly state that null is an allowed option, rather than implicitly allowing it, which is exactly what the error states: "Implicitly marking parameter $var as nullable is deprecated".

I actually think I prefer the use of union types, eg: (PageArray|null $items = null) rather than the obscure question mark, but as we figured out, that requires PHP 8.

Anyway, thanks again for getting this implemented so very quickly so we can all start proper testing of 8.4 with our projects.

[FireWire]

?I've ?been ?type ?hinting ?parameters ?with ?question ?marks ?for ?so ?long ?I ?don't ?even ?see ?them ?anymore.

@ryan Seconding @adrian's many thanks for the PHP 8.4 attention 🙌

Will we see any (Disjunctive|Normal)|(Form&Types) type declarations?

Maybe a contest for longest function signature¿

Wait, did I just break my key¿

[Kiwi Chris]

As someone who writes about as much C# as PHP, ? to indicate nullable parameters is familiar, although if they'd put the ? after the parameter type, it would have meant not having to remember a different position depending on language. At least we don't have to put another upside down question mark at the end of the parameter, for probably the majority of us who don't have Spanish keyboards. 🙂

[Ivan Gretsky]

They need to get us used to some more obscure syntax before they introduce the next logical step - mandatory compilation. So be happy they are boiling the frog slowly and we still have a few more happy years just scripting.

[ryan]

Quote

...so there needs to be some way to explicitly state that null is an allowed option, rather than implicitly allowing it, which is exactly what the error states: "Implicitly marking parameter $var as nullable is deprecated".

@adrian I'm okay with it, but still not really getting it. Null is directly stated as an allowed option by the presence of "= null" in (array $value = null). Or at least that's what I always thought were were doing. If we didn't allow null, we wouldn't declare it as null. I guess what the PHP error states is implicit seems explicit to me. 

I would think where the "?" might make more sense [to me] is if the function declaration were without a default assignment like (?array $value) as an equivalent of (array|null $value) for PHP versions prior to the union type support. That would give us a new enforced limit that we couldn't easily enforce before, at least for PHP versions 7.1 to 8.3. 

Is there something that "?" adds that "= null" doesn't already? Some new ability or enforced limitation that we couldn't easily achieve without it? Even after reading all I can about it, I can't seem to identify what it is. My best guess is it comes from a desire to change the meaning of the language construct to only "optional argument" out of someone's idea of how things should be, maybe influence from another language. Kiwi mentioned C# above, maybe that's where it comes from.  

Quote

I actually think I prefer the use of union types, eg: (PageArray|null $items = null) rather than the obscure question mark, but as we figured out, that requires PHP 8.

I much prefer that as well. Though the "|null" still seems redundant here, but cleaner and with less head scratching, no complaints. It's too bad they didn't just go directly to this in PHP 7.1 as "?" seems like a kludge.

[FireWire]

1 hour ago, ryan said:

Is there something that "?" adds that "= null" doesn't already? Some new ability or enforced limitation that we couldn't easily achieve without it?

Maybe just for consistency? Optimization where the interpreter can reliably determine accepted types from hints alone without parsing default values?

I can't tell how far into the PHP engine this goes and when it turns into a future exception perhaps how PHP handles this underneath the hood may itself change. A speculative example would be that the parser could ignore default values entirely if the arguments being passed/not passed to the function don't match the signature which could be the lone trigger for an exception in that case.

2 hours ago, ryan said:

Even after reading all I can about it, I can't seem to identify what it is.

This was frustrating for me as well. I couldn't find any information about type hints other than their usage. I could be entirely wrong about my thoughts above thanks to that.

As for '?' vs. '|null', I like to use ? in type hints and spell out 'null' in the docblock. It's clear to read when the docblock is referenced by dev/editor tools that will display the full '|null' property description while still keeping the type definition in the method itself shorter so code lines take up less space in code editors. Personal preference, only thing that matters is consistency I guess.

I haven't thought about a lot of this stuff in a long time though since I started declaring strict_types in every file and got set in my ways years ago. I consider that choice a luxury though because I'm not in a position where I ensure the kind of wide version support and foundational stability that ProcessWire does.