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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
