PHP: Update from v7 to v8

I’ve been using PHP 7.4 for a while now. It’s very nice. But I feel that I need to move to v8.

I set up a new instance and started checking for errors.

I use associative arrays quite a bit which are very similar to Xojo dictionaries. Well, PHP 8 does not like values being accessed that are not set. PHP 7 started to use stricter types. PHP 8 is much stricter. So when I try to use a value that is not set, I get the following warning:

PHP Warning:  Trying to access array offset on value

I want to write better code, so I’m interested in fixing that, but the code works great in PHP 7.

I started to add a function to test if the value is set or null, but PHP didn’t like passing a value that is not set.

The fix is to test for using coalescing which returns the value after the ?? if the variable does not exist.

$x ?? "";

I’m considering turning off warning, but I’d prefer not to…

I should say that I REALLY like non-strict types. FileMaker and PHP 7 work super well without getting crazy with setting value types.

That said, I use types for classes, just not for int, string, etc…

Trouble is NON-strict types only reveal bugs at runtime :frowning:
Compilers that are super strict force you to be explicit about type conversions & so many other things at compile time

They force you to deal with issues like this at compile time BEFORE you deploy & have users screaming at you

In many situations FileMaker doesn’t issue a warning when a type mismatch occurs or a NIL is queried. This can lead to surprising results and I rather have the warnings, at least.
Warnings and strong types can be annoying, especially when porting legacy code. They do lead to better code…

I might be starting to agree with that.

I just found a few bugs already. :slight_smile:

are u aware that everything PHP 7.x is EOL and mustnot be used on public web-facing servers?

Yep. That’s why I’m working to convert to 8.

But 7 can still be used on public servers.

PHP gives you a few options to avoid the warning, but like you, the null coalescing operator is one of my favorites. You could do $value = isset($array[$key]) ? $array[$key] : $fallback or $value = array_key_exists($key, $array) ? $array[$key] : $fallback to achieve the same thing. But $value = $array[$key] ?? $fallback is just so much cleaner. And you can of course chain them, so $value = $array[$keyA] ?? $array[$keyB] ?? $fallback is valid too.

Starting ? :stuck_out_tongue:

while compilers dont usually catch logic errors catching conversion errors etc is super handy

learned that one long ago & far away working on payroll systems

folks get really snarky when their pay isnt right

One conversion from NUMERIC(15,4) to NUMERIC 15,3) caused some weird rounding issues and the compiler caught that
We could have converted it but would have to have explicitly done so
We saw the error it could cause and didnt


1 Like

PHP so often reminds me of PERL where it just pukes punctuation everywhere :slight_smile:

They are similar in many regards. PERL was my very first language, so the transition to PHP was very easy way back when.

I’ve long been accustomed to early-bound / strict typing via C# and even to a large extent VB.NET, and find it on balance a significant boon. But I really don’t like the way .NET 5+ has gone all-in on trying to prevent unhandled nulls. I have shut off most of the warnings and still get some of them. In some cases they are plain wrong. For example if you assign a variable from a SqlDataReader like so:

string foo = reader[“Foo”].ToString();

You get syntax highlighting that warns that foo might have a null value. But ToString() on a DataReader indexer returns the empty string if the underlying DB value is NULL. I have known this for years; I’m surprised that MSFT doesn’t :-\

Similarly if I have a field initialized like so:

string _someField = null;

… Then the compiler whines unless I pretend string is not normally nullable, but can be:

string? _someField = null;

This one I can squint and look at it sideways and KIND OF see what they are going for, which is indicating explicit intent that _someField might sometimes contain a null. But it’s confusing because string, like any other reference type, is inherently nullable. It’s like your declarations now have to answer some ever-hovering Auditor’s question, “Are you sure? Are you REALLY sure?”

In this respect C# is evolving into a language that doesn’t treat devs like adults. These changes feel like they check off some requirement written by a non-dev who once read an article titled, “Null considered harmful”.

I mean, .NET even has nullable types (int?, decimal?, datetime? etc, not null decorators on reference types) to support null semantics when you need them. And sometimes you really DO need them. Why provide support for null and then badger users about nulls?

So … not all compiler bondage and discipline is created equal :wink:

My point really is that I’d like the errors / warning at compile time not runtime
But yeah I’ve run into the C# madness too :slight_smile:

So, I’m kind of digging the PHP 8 changes. While it’s a pain, I did find a few minor bugs. So that’s a plus…

I think all the bugs I ran into were:

  • Not checking for null
  • Not initializing a couple vars

So in the long run, finding more bugs is good! :slight_smile:

1 Like

I really like the Go linter as it reveals the errors in real time. No need to compile to find the errors.

That was one of the things that I despised when I went back to Xojo a few weeks ago. What do you mean I’m not informed of my stupidity until I try to compile? Something like that would be useful to EVERY Xojo developer today. Instead we got API 2 and Android.

1 Like

Oh sure I like live code advice like that as well
VS with C# does that
Android Studio does that in the flutter & dart apps I’m working on

Getting those kinds of tips earlier is way better than finding out a runtime that some code has magically converted “foobar” into “0” and wiped out your database as a result :slight_smile:

Deep integration with the compiler uh … has requirements
I dunno if they could do it or if anyone there has the knowledge or skills to do it

1 Like

Well holy shit, I just realized PHP 8 supports named parameters. That’s awesome.

1 Like