Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119834
Message-ID: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
Date: Sat, 8 Apr 2023 20:36:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
To: internals@lists.php.net
Content-Language: de-DE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Future stability of PHP?
From: stephan.soller@helionweb.de (Stephan Soller)

Hello,

I'm sorry if this isn't the correct mailing list for that discussion but I
couldn't find a more appropriate one where people actually know how the 
wind is
blowing.

A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
deprecations and fatal errors spooked me a bit (details below if you're
interested). That got me wondering about the long-term stability of PHP 
(as in
language and API breaks) and I looked at the RFCs. I got the impression that
static typing has a lot of traction now and I have no idea of what the 
fallout
might be of changing a dynamically typed language into a statically 
typed one.
Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled
across the language evolution RFC proposals but it seems that approach was
abandoned.

Is there a way to tell which APIs and language features will be stable 
and which
might get changed or removed in the future? That way I could restrict 
myself to
a stable subset for long-running projects (5 to 10 years). But I realize 
that
such guarantees are difficult (or contra productive) when a language is 
in flux
and I can understand if no one wants to do something like that.

Some of my projects run for 5 to 10 years, in one case even 20 years. 
Usually
without or with very little code changes. My usual tool set for web projects
like that is plain PHP, HTML, CSS and JS. Everything without any 
frameworks or
unnecessary libraries and kept as simple as possible. If possible I just use
builtin and stable APIs and usually end up without any or with just one 
or two
dependencies (e.g. PDF generation). This isn't pretty and I end up 
trading a bit
of productivity for long-term stability. I know this is quite an unusual
approach, especially in todays web development world. But I've been 
developing
stuff for over 20 years and in most cases I have to maintain my own code (my
first PHP project was about 20 years ago). Without that somewhat unusual 
focus
on stability I would spend my whole time updating existing code and 
couldn't get
anything new done. And let's face it, in most situations you don't need the
perfect tool, just something that gets the job done reliably (e.g. sending a
query to a database and process the result). So I guess that is my 
usecase for
PHP: A stable base for long-lasting and very low maintenance server-side 
code.
The recent migration made me question that assumption, though.

Is this still something that makes sense in your opinion or would you 
recommend
to avoid using PHP for that?

A project like PHP is the result of a lot of work from many different 
people and
people, opinions and priorities change over time. The direction of PHP is
determined by those who work on it and that's a good thing. I just want 
to avoid
using the wrong tool for the job as this can quickly spiral into a lot of
unnecessary complexity and (in a somewhat best case) end in a rewrite a few
years later to stop the spiral.

I routinely rely on PHP features that are not often talked about (read 
on sexy
or fashionable) to greatly simplify my code: The alternate syntax for 
control
structures as a lightweight template system, implicit type conversions, 
streams,
SimpleXML, a DOM parser that can actually parse real-world HTML, PDOs 
and so on.
PHP has a lot of small nuggets that make it a pretty useful toolbox if 
you don't
overdo it. But did I overdo it? What I didn't realize before was the 
extend to
which I relied on the stability of APIs and core extensions listed in 
the PHP
manual. What will end up on the chopping block in the next few years? 
Can I rely
on the alternate syntax for control structures? Will streams go since 
HTTP 2 and
3 made a mess of the whole HTTP protocol? I'm note sure how to evaluate the
current situation. Hence the post.

Migration details for those who're interested:

I had PHP pegged as a dynamic language at it's core so I've used 
techniques like
duck typing and dynamic properties here and there when they were the best
compromise for simplicity and code locality.  This is nothing you would 
use in
large or inexperienced teams but for a lot of small stuff this can keep code
simple (it it doesn't amount to more than a few hundred lines). 
Sometimes I let
projects grow organically like that over a few years until we 
consolidate parts
that became to complex once the usecases became clear. Unfortunately this
backfired on me during a recent migration. The amount of deprications 
and out
right fatal errors caught me off guard. Dynamically extending objects got
deprecated in PHP 8 except for stdClass and the AllowDynamicProperties 
attribute
which sounds reasonable. Unfortunately I ran right into the corner case of
attaching dynamic properties to a Generator which caused a fatal error. 
The rest
of the code then used duck typing to work with those properties 
(basically just
isset() checks that use the additional information if its available). In 
the end
I found a solution using an anonymous class that implements the Iterator
interface. But this is different between PHP 7 and 8 (because of the 
mixed type)
so I had to implement my first version switch in PHP… which felt quite 
weird. I
usually only have to do that in C to support corner cases for quirky 
compilers.
So this spooked me quite a bit.

Sorry for the long wall of text.

Happy programming
Stephan