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.

Yet another year in The Data Warehouse - 2025

The Data Warehouse is still live and kicking. 25th year anniversary is coming 2026. From a very modest start 2001 it has a steady growth until about 2018 both in terms of users (+300) and workflows (+3000/day). Workflows extracting data from ERP systems massaging data, creating reports, apps, mails and acting as a data hub for external apps and GUIs. Now users and workflows are decreasing but not as fast as we wish (I'm a bit tired of  the DW, but I will maintain it until it is decommissioned, no date sat yet. 

 This year we upgraded all servers to Ubuntu 2022.04 for security reasons and I'm planning to upgrade MySQL for the same reason. I will also make an attempt to upgrade PHP to vs 8.4 if there is not too much work. These upgrades has been planned for a very long time, but there is always things coming up.  Data Warehouses are very dependent of their surroundings and thus vulnerable to disturbances in the IT landscape. Plus, most apps are never done; they evolve until they are dead. This includes the dying DW.  

 I am responsible for a stupid workflow updating currencies. At the time the currency workflow was created, it was almost decent, a manual process of extracting currencies from an Excel and downloading some extra currencies from SAP. This has to be done on the last working day of the month. Now in the last hours of 2025 I am together with an Indian colleague waiting for the SAP ERP system to update some currencies before we can update the DW currencies. this will happen around 2 pm CET, which means new year parties already started in India.  

 The Data Warehouse is written mainly in spare time between 2001 and 2006 with no proper maintenance since 2012. And it shows, in 2012 the DW was in a league of its own. Today there are a number of options that are as good or better. Two friends of mine (Camilla Hillero and Andreas Roine-Larsson)  have created successful data -warehouse/-lake/-lake house or whatever they are called, using Snowflake and Clickhouse, they are equally pleased of their own choices. 

 At last a happy new year and my best whishes for 2026😀 

Yet another year in The Data Warehouse

 2001 I created the data warehouse. The reason was to help a purchaser with a forecast report. It would have been easy just to create a paper report from the mainframe ERP system I created 1979, but I wanted to create a better tool for business analyzing and reporting, but I did not get founds to by any software, so I had to create a system from what I had and free software. I was pretty sure the data warehouse would be around for some ten years or so, but not for twenty three years, still counting! I some years ago wrote that the swan song for the data warehouse had begun, it is a very long tune indeed. I would not be overly surprised if I can celebrate a twenty fifth jubilee next year. 

Of course I have not done The Data Warehouse alone, I made the infrastructure and the tools to import and massage the data. Most reports, marts, apps etc, have been made by others, not to forgot the operations. A data warehouse is a complex piece of machinery that needs supervising, maintenance and tinkering 24x7.

For this year I expect to finalize the PHP 7.4 to 8.4 conversion, this is my worst job ever and I have done a lot of really bad jobs during the years. This upgrade is something I'm forced to do, I really did not want to do it, but you do not argue with IT security. I also need to upgrade MySQL. Both these things should have been done ages ago. But now I have to do it boring, boring, boring. 

When I retired I said 'From now on I only do fun things that interest me.' Since then I only do boring things or even worse, I had to maintain some SharePoint apps for some years, that was hopefully the low moment of my years in IT. I have for some ten years wanted to start D programming, but I can not muster the energy needed to learn D. I also have looked at Raku but have not started yet. And now I'm looking at Java script again! I really hope I can muster energy this year to restart my career, I'm still only seventy one. 

Trick from Walter Bright

 Yesterday I learnt a neat syntactical trick from Walter Bright founder of the D language.

do
{
    if (x) break;
    if (y) break;
    if (z) break;
    hotPath();
} while (0);

This is very useful if you like me often have more than one return from functions and subroutine. For many reasons you only want one return point. This little trick may come handy in some situations. 

I recommend the D language page https://dlang.org/ if you are interested in Programming in general. I found the discussions of the D language itself very interesting.