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…
Trouble is NON-strict types only reveal bugs at runtime
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…
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.
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
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
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.
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
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
