Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119940
To: internals@lists.php.net,Stephan Soller <stephan.soller@helionweb.de>
Message-ID: <007b5106-5ba5-a093-0076-40a737a3ed2e@telia.com>
Date: Tue, 11 Apr 2023 20:26:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Content-Language: en-GB, sv
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
In-Reply-To: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Future stability of PHP?
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2023-04-08 kl. 20:36, skrev 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

Hi,

My 50c and a bit casual reflection on that is:
- When we upgraded a PHP 5.2 codebase to first 5.6 and later to 7.0 it 
was a breeze. Also the open source libraries that we used was straight 
forward to migrate.
- Now when going from 7.4 that we still use today to 8.x it was a longer 
process also because we need to wait out the open source libraries to 
migrate. Today we just need to gather ourselves and do the effort, so 
our codebase is ready for 8.x migration.
- The the PHP 7.x release has really provided a tremendous value in 
terms of new features, which also the 8.x serie does, but the 
deprecations are more cumbersome.

So I think there is a need here to:
- Not just look at deprecations on one release, but one should instead 
look at them for a complete release cycle for all 8.x releases and say 
at some point that the deprecation quota is filled up, i.e. no more 
deprecations for 8.x.
- And when piling up these deprecations that will hit harder in 9.0 one 
have to take into account what added value will 9.0 bring. There has 
been some old RFC's that was rejected and maybe these can be brought to 
life again for 9.0 to bring added value besides completely new features. 
E.g. one of my favourites was the Pipe operator RFC.

Regards //Björn L