Killing PHP

 Going from php 8.3 to php 8.4.

This works perfectly fine in php 8.3:

function dumpit($msgtype,$var, &$val){...}

$log->dumpit('Trace','calling_process',trim($pidout));

The reference in the dumpit function signature is wrong, it should not be there. PHP up to version 8.3 was smart enough to recognize that and just execute the code. Very PHPish try to do what the coder intended.

Some structural fascist changed vs 8.4 made that a fatal error, I have words for such persons. A more reasonable approach write a warning or a depreciation msg.

This is killing PHP, makes it bland and gloomy, be as any run-of-the-mill language. It makes me sad.

 

Upgrading PHP

 I'm on my way upgrading The Data Warehouse engine PHP to version 8.5. The DW was originally written in  vs 4. As I recall it, the transition to vs 5 and vs 7, was simple. The upgrade to vs 8 was another matter entirely.

PHP was a language with relaxed syntax, e.g. allowing all kinds of comparing between value types, PHP had very good defaults making even stupid compare mostly came out right, it was PHPish. PHP honored getting things done not being picky about correctness, PHP tried to follow the intention of the coder and did a very good job at doing so. This infuriated structural fascists who's whining made the PHP    maintainers straighten up the language in vs 8, disallowing constructs in my PHP code that had worked well for some 20 years. If you have a large code base that old you just do not remember why a null array is compared with a blank char no matter how good the documentation is. The adjustment (not clean up)  to version 8 took a long time. 

Now going from 8.1 to 8.2, 8.3, 8.4 and 8.5 is a walk in the park. I'm on vs 8.2 now and will put 8.3 in production coming week. Then I will probably wait with 8.4 and 8.5 to September. The vacation period in Sweden starts late June and ends in Central Europe late August, during this period I avoid changes. 

Still alive

 The old work horse 'The Data Warehouse" keeps on running. Just upgraded PHP to vs 8.2. Otherwise not much is happening, I tried to create a somewhat saner routine for importing currency rates using power shell script, first attempt failed. A persistent cache, was not so persistent and I could not freely transport the script between clients, both probably due to security reasons, I did not bother to find out the root cause. I make one more attempt, if that do not work I keep the old insane routine. 

Claude's assessment of my Data Warehouse code

For what it's worth.

Over the seven directories I've (Claude) analyzed so far (include/, opsproc/, proc/, actaproc/, cpdproc/, blmproc/, fujiproc/) , the codebase has been remarkably well-written: ~30,000 lines reviewed

 No class-based dynamic-property issues 

No removed-extension dependencies in the active set (saprfc/sapnwrfc aside, which is a separate question) 

All compatibility issues are surface-level (cast keywords, csv argument defaults) That tells me the original author understood what they were doing. A system that small-edit-friendly after 20 years of PHP changes isn't going to suddenly break in deep ways from a PHPMailer point release. 

Run a representative schedule, watch the log, you'll know within minutes. Good luck with the deployment. 

 You said: Thank you very much for the appreciation of my work. The bulk code was written in PHP vs 4 between 2001 and 2007. 

 PMClaude responded: That's genuinely impressive. PHP 4 to PHP 8.5 is a 24-year span covering some of the most disruptive changes in the language's history — full object model rewrite in PHP 5, namespaces in 5.3, removal of mysql_* and ereg_*, the entire type system getting tightened, magic quotes gone, register_globals gone, the whole each()/create_function() removal, and the steady drumbeat of strictness in 7.x and 8.x. 

Most PHP 4 code from that era simply doesn't survive to the present day. The codebases that do tend to share certain habits, and yours has them: Procedural with clear data flow. The $context / $schedule / $job array conventions threading through every function is exactly the kind of discipline that pays off over decades. No hidden global state to keep "rediscovering." 

Defensive coding. array_key_exists checks, ?? FALSE fallbacks, explicit handling of "is the log object available yet" — those if ($log) $log->logit(...) patterns. 

Code from that era written without that discipline turned into warning-storms by PHP 7 and just rotted. One class with declared properties (log2.php) instead of dozens with implicit ones — that's probably the single biggest reason the PHP 8.2 dynamic-property deprecation was a non-event for you. 

People who wrote PHP 4-style classes with $this->whatever = ... sprinkled wherever convenient are still cleaning that up today. Schedule-driven architecture. Having the XML schedules carry the volatile/customer-specific logic (with eval as the escape valve) and keeping the engine itself stable is exactly why the engine could survive five major PHP versions. 

The XML-driven job scheduler/ETL pattern was actually quite forward-looking for 2001. A lot of what came later in the workflow-orchestration world (Airflow, Luigi, Argo) ended up at similar conclusions: declarative job definitions in a structured format, an engine that compiles them into executable graphs, prereq/exit-status semantics, named context that flows between steps. 

 The Lasse's Application Processor (C) 2006, 2026 Lars Johansson line in your scriptS.php that's a 20-year copyright span on a system you're still maintaining. That's a rare thing in any language and especially rare in PHP.

Hope the PHP 8.5 deployment goes smoothly and that adac keeps running another decade.