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 Stephan,
Generally, PHP tries to keep as much backwards compatibility as possible.
Breaking changes are limited to minimum and done in the least obstructive
way possible. When a deprecation is introduced, you have at least 3 years
to update your code.
But PHP also tries to move forward and the language improves each year. We
certainly got many more features than breaking changes. Just think of match
expression, enums, attributes, constructor property promotion, new Random
API, readonly properties/classes, first-class callable, consistent errors
and many more.
The biggest improvement in PHP 7 and 8 was a comprehensive type system.
It's something that you don't have to use, therefore doesn't affect
existing code much, but makes development so much more enjoyable and less
bug-prone. I know I have discovered many bugs because of migration to PHP 8
and introduction of proper types.
And this is the direction PHP is going in. The language is still dynamic
and allows for taking the easy route, but new features focus on reducing
bugs by making the code's behaviour less surprising.
If you try to adhere to clean code principles, upgrades should not be a
huge problem. Use static analysis and good tests. Learn and follow clean
code practices, e.g. SOLID. Use abstraction in your code; it's better to
change code only in one place than change it across hundreds of files. Some
tools help you during migrations, such as Rector and phpcbf, but to use
them proficiently, your code needs to be free from surprises. Dynamic
properties are a very good example of surprising behaviour. By looking at
the definition of the class, you don't know what properties it has. If any
of the methods use undefined properties, both you and static analysers will
be surprised by this.
There are certain things you should avoid in your code like fire. Not
because they might be removed from the language, but because they make your
code unclean and cause bugs. Here is my list:
- Arrays. Yes, they are a major feature of the language but also a major
pain in the... Use proper data structures, which may use arrays internally,
but don't use bare arrays in your code. Value objects and DTOs are
invaluable. - Isset and empty. They are sometimes necessary and sometimes they are the
easiest choice, but they hide so many bugs. Every time you use any of them,
it should raise an immediate red flag. - References. I don't understand why the language still has this feature.
Hack got rid of it and that was a very smart decision. You don't need
references. Use them almost never. - Globals and superglobals. This should not need explaining. Pretty much in
every language, these are pure evil. They make changes to the code an
experience similar to disarming a bomb. It's tempting to use $_GET, $_POST,
$_REQUEST anywhere in your code, but if you want to avoid bugs and
surprises, you'd better stay away from it. There should probably be at most
one place in every project where these are used. -
extract()andcompact(), and variable variables. These should only be
used in a very tightly controlled scope, and even then, their usage can be
contested. Ideally, variable variables should not exist in the language; we
have arrays after all. - Sanitizing filters. Sanitization is too ambiguous term to be useful. What
you should be using is validation and formatting. Validate your inputs to
make sure they are the type/value you expect. Format the output so that it
can't break the context it is in. - Loose comparison. I have liked that about PHP in the past, but in recent
years I became a strong supporter of strict comparison. Why? Because "0" ==
false. Forbid using loose comparison in your coding standard and forget
that it exists. Don't let the language make a fool out of you. You are the
developer and you know what type you expect.
Following these guidelines will not only help you avoid bugs in your code
but also will make the upgrade process much less cumbersome. This and
adhering to the strictest level of the static analysis tool of your choice
is the recipe for success.
Try to stay up to date with the changes. Every year when PHP releases a new
version, go over the changelog and make an effort to learn and use new
features. Even if your production is 3 years behind, you can try these out
in your development environment.
PHP will move forward and add new features, but sometimes it must also
break some things to move forward.
Kind Regards,
Kamil Tekiela
I agree with the OP's sentiment here. If I was starting a codebase from
scratch today, I'd probably go with Node. I find that writing modern
JavaScript is way easier than writing PHP these days, and the breaking
changes in newer PHP versions make writing code harder rather than easier.
PHP is the foundation for many legacy codebases, and breaking old projects
isn't really a great selling point of new PHP versions.
Hopefully this scenario will affect enough people that 7.4 will continue to
be maintained by some group of people into the foreseeable future.
Best,
Dan
Hi Stephan,
Generally, PHP tries to keep as much backwards compatibility as possible.
Breaking changes are limited to minimum and done in the least obstructive
way possible. When a deprecation is introduced, you have at least 3 years
to update your code.
But PHP also tries to move forward and the language improves each year. We
certainly got many more features than breaking changes. Just think of match
expression, enums, attributes, constructor property promotion, new Random
API, readonly properties/classes, first-class callable, consistent errors
and many more.
The biggest improvement in PHP 7 and 8 was a comprehensive type system.
It's something that you don't have to use, therefore doesn't affect
existing code much, but makes development so much more enjoyable and less
bug-prone. I know I have discovered many bugs because of migration to PHP 8
and introduction of proper types.
And this is the direction PHP is going in. The language is still dynamic
and allows for taking the easy route, but new features focus on reducing
bugs by making the code's behaviour less surprising.If you try to adhere to clean code principles, upgrades should not be a
huge problem. Use static analysis and good tests. Learn and follow clean
code practices, e.g. SOLID. Use abstraction in your code; it's better to
change code only in one place than change it across hundreds of files. Some
tools help you during migrations, such as Rector and phpcbf, but to use
them proficiently, your code needs to be free from surprises. Dynamic
properties are a very good example of surprising behaviour. By looking at
the definition of the class, you don't know what properties it has. If any
of the methods use undefined properties, both you and static analysers will
be surprised by this.There are certain things you should avoid in your code like fire. Not
because they might be removed from the language, but because they make your
code unclean and cause bugs. Here is my list:
- Arrays. Yes, they are a major feature of the language but also a major
pain in the... Use proper data structures, which may use arrays internally,
but don't use bare arrays in your code. Value objects and DTOs are
invaluable.- Isset and empty. They are sometimes necessary and sometimes they are the
easiest choice, but they hide so many bugs. Every time you use any of them,
it should raise an immediate red flag.- References. I don't understand why the language still has this feature.
Hack got rid of it and that was a very smart decision. You don't need
references. Use them almost never.- Globals and superglobals. This should not need explaining. Pretty much in
every language, these are pure evil. They make changes to the code an
experience similar to disarming a bomb. It's tempting to use $_GET, $_POST,
$_REQUEST anywhere in your code, but if you want to avoid bugs and
surprises, you'd better stay away from it. There should probably be at most
one place in every project where these are used.extract()andcompact(), and variable variables. These should only be
used in a very tightly controlled scope, and even then, their usage can be
contested. Ideally, variable variables should not exist in the language; we
have arrays after all.- Sanitizing filters. Sanitization is too ambiguous term to be useful. What
you should be using is validation and formatting. Validate your inputs to
make sure they are the type/value you expect. Format the output so that it
can't break the context it is in.- Loose comparison. I have liked that about PHP in the past, but in recent
years I became a strong supporter of strict comparison. Why? Because "0" ==
false. Forbid using loose comparison in your coding standard and forget
that it exists. Don't let the language make a fool out of you. You are the
developer and you know what type you expect.Following these guidelines will not only help you avoid bugs in your code
but also will make the upgrade process much less cumbersome. This and
adhering to the strictest level of the static analysis tool of your choice
is the recipe for success.Try to stay up to date with the changes. Every year when PHP releases a new
version, go over the changelog and make an effort to learn and use new
features. Even if your production is 3 years behind, you can try these out
in your development environment.PHP will move forward and add new features, but sometimes it must also
break some things to move forward.Kind Regards,
Kamil Tekiela
It depends on your environment and usecase.
For me Node is actually a curious case. Node itself and its APIs are
very stable and the stability of each API is clearly marked in the docs.
But the NPM based ecosystem is almost the exact opposite. Using it for
anything else than quick experiments or throw-away prototypes is a
maintenance nightmare for people like me. Maybe you can amortize that in
larger companies with an operations department but from what I heard and
observed over the years admins and programmers don't tend to talk much
with each other and most programmers have no idea what it takes to keep
their code running. And I can deeply emphasize with every admin who has
to keep a node project with hundreds of dependencies running for more
than a few months. Lets not even talk about security.
Nodes core APIs are pretty network centric (that's where it came from)
and it was a good fit for a HTTP based Matroska video streaming server
project (among other things). But as it turns out JavaScript is a pretty
bad language if you need bit manipulation with 64 bits. I'm still
curious why they made BigInt signed one's-complement… Writing that stuff
in C was a lot simpler.
As for websites with node but without NPM... I did that a few times but
for the last two years I tend to use Python aiohttp instead. They have
well maintained Debian packages and builtin websocket support. And very
complex client-server interactions are often the threshold where I
switch from webservers like Apache or Nginx to an application server.
As for using PHP for new code bases: I think a lot of programmers
underestimate the flexibility and simplicity of file based webservers
like Apache with PHP. If you keep it simple they allow projects to grow
organically. Need a new backend for something? Just put a few lines of
code into a new PHP file. No update to a centralized application server
or routes required. Want to have a search-engine friendly dynamic
website? Just write a basic HTML page with a few lines of PHP in it to
insert the actual data (the alternate control structure syntax basically
gives you a builtin template system). Want to generate static pages
instead? Use output redirection. Want to add simple user authentication?
Add a password protection in the webserver. Or tell it to get the user
data from LDAP if you're in a company. It plays well with source
control, there are a lot of dirt cheap webhosters for small customers,
the list goes on and on. All of that makes PHP a pretty good tool that
can solve a lot of problems in very simple ways.
A lot of that are just small projects, small customers or the inglorious
everyday work that nobody likes but someone has to do. So it doesn't get
talked about much. Big companies and teams on the other hand spend a lot
of time talking about what they do and then there are also consultants
that preach whatever sells today. Most tend to talk about what everyone
else is doing and this doesn't necessarily has anything to do with a
simple solution for your specific problem at hand.
Of course all of that can flip on a dime depending on your environment:
Part of a team where everyone has decades of Java experience? You're not
using PHP, or node for that matter. Doing a project with a lot of
rookies that only know stuff like express and react? Guess what you'll
be using. Part of a team where everyone has their dedicated
non-overlapping area of responsibility and authority (content, design,
programming, etc.)? Now there is potential to use the right tool for the
job. And PHP can be just that in a lot of situations.
Happy programming
Stephan
I agree with the OP's sentiment here. If I was starting a codebase from
scratch today, I'd probably go with Node. I find that writing modern
JavaScript is way easier than writing PHP these days, and the breaking
changes in newer PHP versions make writing code harder rather than easier.
PHP is the foundation for many legacy codebases, and breaking old projects
isn't really a great selling point of new PHP versions.Hopefully this scenario will affect enough people that 7.4 will continue to
be maintained by some group of people into the foreseeable future.Best,
DanHi Stephan,
Generally, PHP tries to keep as much backwards compatibility as possible.
Breaking changes are limited to minimum and done in the least obstructive
way possible. When a deprecation is introduced, you have at least 3 years
to update your code.
But PHP also tries to move forward and the language improves each year. We
certainly got many more features than breaking changes. Just think of match
expression, enums, attributes, constructor property promotion, new Random
API, readonly properties/classes, first-class callable, consistent errors
and many more.
The biggest improvement in PHP 7 and 8 was a comprehensive type system.
It's something that you don't have to use, therefore doesn't affect
existing code much, but makes development so much more enjoyable and less
bug-prone. I know I have discovered many bugs because of migration to PHP 8
and introduction of proper types.
And this is the direction PHP is going in. The language is still dynamic
and allows for taking the easy route, but new features focus on reducing
bugs by making the code's behaviour less surprising.If you try to adhere to clean code principles, upgrades should not be a
huge problem. Use static analysis and good tests. Learn and follow clean
code practices, e.g. SOLID. Use abstraction in your code; it's better to
change code only in one place than change it across hundreds of files. Some
tools help you during migrations, such as Rector and phpcbf, but to use
them proficiently, your code needs to be free from surprises. Dynamic
properties are a very good example of surprising behaviour. By looking at
the definition of the class, you don't know what properties it has. If any
of the methods use undefined properties, both you and static analysers will
be surprised by this.There are certain things you should avoid in your code like fire. Not
because they might be removed from the language, but because they make your
code unclean and cause bugs. Here is my list:
- Arrays. Yes, they are a major feature of the language but also a major
pain in the... Use proper data structures, which may use arrays internally,
but don't use bare arrays in your code. Value objects and DTOs are
invaluable.- Isset and empty. They are sometimes necessary and sometimes they are the
easiest choice, but they hide so many bugs. Every time you use any of them,
it should raise an immediate red flag.- References. I don't understand why the language still has this feature.
Hack got rid of it and that was a very smart decision. You don't need
references. Use them almost never.- Globals and superglobals. This should not need explaining. Pretty much in
every language, these are pure evil. They make changes to the code an
experience similar to disarming a bomb. It's tempting to use $_GET, $_POST,
$_REQUEST anywhere in your code, but if you want to avoid bugs and
surprises, you'd better stay away from it. There should probably be at most
one place in every project where these are used.extract()andcompact(), and variable variables. These should only be
used in a very tightly controlled scope, and even then, their usage can be
contested. Ideally, variable variables should not exist in the language; we
have arrays after all.- Sanitizing filters. Sanitization is too ambiguous term to be useful. What
you should be using is validation and formatting. Validate your inputs to
make sure they are the type/value you expect. Format the output so that it
can't break the context it is in.- Loose comparison. I have liked that about PHP in the past, but in recent
years I became a strong supporter of strict comparison. Why? Because "0" ==
false. Forbid using loose comparison in your coding standard and forget
that it exists. Don't let the language make a fool out of you. You are the
developer and you know what type you expect.Following these guidelines will not only help you avoid bugs in your code
but also will make the upgrade process much less cumbersome. This and
adhering to the strictest level of the static analysis tool of your choice
is the recipe for success.Try to stay up to date with the changes. Every year when PHP releases a new
version, go over the changelog and make an effort to learn and use new
features. Even if your production is 3 years behind, you can try these out
in your development environment.PHP will move forward and add new features, but sometimes it must also
break some things to move forward.Kind Regards,
Kamil Tekiela
I agree with the OP's sentiment here. If I was starting a codebase from
scratch today, I'd probably go with Node. I find that writing modern
JavaScript is way easier than writing PHP these days, and the breaking
changes in newer PHP versions make writing code harder rather than easier.
PHP is the foundation for many legacy codebases, and breaking old projects
isn't really a great selling point of new PHP versions.Hopefully this scenario will affect enough people that 7.4 will continue to
be maintained by some group of people into the foreseeable future.Best,
Dan
Can't disagree with this statement. I love PHP. I have been working with it
for 13 years now. I can also make things work with PHP 8+ and I get what it
brings. But the cost is catastrophic. If you have a legacy codebase hanging
over your head you probably know how hard it is to upgrade it. If you have
greenfield project with SA and 100% coverage, it's a peach.
But what's the point of starting a greenfield project in PHP while
Typescript is right there? The cost of PHP maintenance and it's bad
reputation certainly makes it a language only for those that got hooked
into it a decade ago and not something that makes sense to recommend for
newcomers. With each deprecation, PHP pushes out more devs and companies
into a different path.
But what's the point of starting a greenfield project in PHP while
Typescript is right there?
If that is true then we have pushed PHP to its death. PHP is dead and we
can move on to other projects. But that's obviously not true. I could claim
the complete opposite: why start a project in Typescript when PHP is there
and it's a more mature language? At the end of the day, it comes down to
personal preference. The language is perfectly suitable for greenfield
implementation. If it wasn't, then there would be RFCs trying to change
things that are wrong with it.
But the cost is catastrophic. If you have a legacy codebase hanging over
your head you probably know how hard it is to upgrade it.
I wonder about this every time I hear this claim. What exactly changed in
PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may
be a little more difficult because of some of the recent deprecations, but
that's still years ahead of us. So what's exactly driving people away from
PHP 8? Why is the adoption dwindling?
I'd rather say that the roadblocks people are facing in upgrading legacy
projects are not specific to PHP 8, but rather a technical debt acquired
over the past 10-15 years. Even if nothing would change in PHP 8, people
would still complain about the upgrade because of unrelated reasons. But
please prove me wrong. Is there actually any change in PHP 8.0 that is a
major source of work?
If PHP went in the wrong direction, let's suggest something to fix it. If
there are no suggestions for improvement then what are people complaining
about?
Regards,
Kamil
But the cost is catastrophic. If you have a legacy codebase hanging over
your head you probably know how hard it is to upgrade it.I wonder about this every time I hear this claim. What exactly changed in
PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may
be a little more difficult because of some of the recent deprecations, but
that's still years ahead of us. So what's exactly driving people away from
PHP 8? Why is the adoption dwindling?I'd rather say that the roadblocks people are facing in upgrading legacy
projects are not specific to PHP 8, but rather a technical debt acquired
over the past 10-15 years. Even if nothing would change in PHP 8, people
would still complain about the upgrade because of unrelated reasons. But
please prove me wrong. Is there actually any change in PHP 8.0 that is a
major source of work?If PHP went in the wrong direction, let's suggest something to fix it. If
there are no suggestions for improvement then what are people complaining
about?Regards,
Kamil
Here are the top-of-my-head most relevant stuff I've read over the years on
the matter.
https://yoast.com/developer-blog/the-2020-wordpress-and-php-8-compatibility-report/
https://markbakeruk.net/2022/05/22/php-8-2-the-release-of-deprecations/
https://24daysindecember.net/2022/12/06/evolving-php/
https://24daysindecember.net/2022/12/19/maintenance-art/
https://mobile.twitter.com/jrf_nl/status/1459221549429542920
https://24daysindecember.net/2020/12/21/a-perfect-storm/
https://mobile.twitter.com/jrf_nl/status/1558589727766417411
Unfortunately I couldn't find where, but I remember reading that PHP 7.2
deprecation of non-countable types was one of the biggest "busywork"
generator of the PHP 7 series. It made an extremely large impact at public
and private projects across the world for something with questionable
benefits.
https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types
Over the course of PHP 7 and 8, there were significant concerns on how
problematic PHP deprecations and breaking changes were. Now we're starting
to see the result of such concerns being ignored. This isn't the first time
someone mentions on PHP internals that it's getting harder and harder to
stay with PHP, but it's never really received with an open mind. It's
either "you don't have to run deprecation-free code" or "you've had years
to get rid of that deprecation error, tough luck if you didn't".
I love PHP and I built my career around it. I have zero interest in
starting from scratch in another language, but I've lost count on how many
projects, friends and companies around me have already made the switch to
Typescript. It's getting harder and harder to argue in favour of staying
with PHP.
--
Marco Deleu
Over the course of PHP 7 and 8, there were significant concerns on how
problematic PHP deprecations and breaking changes were. Now we're starting
to see the result of such concerns being ignored. This isn't the first time
someone mentions on PHP internals that it's getting harder and harder to
stay with PHP, but it's never really received with an open mind. It's
either "you don't have to run deprecation-free code" or "you've had years
to get rid of that deprecation error, tough luck if you didn't".I love PHP and I built my career around it. I have zero interest in
starting from scratch in another language, but I've lost count on how many
projects, friends and companies around me have already made the switch to
Typescript. It's getting harder and harder to argue in favour of staying
with PHP.
The PHP ecosystem even just in the last 10 years has changed completely,
with composer, more mature frameworks, easily usable independent
components and even static analyzers. For me that ecosystem is the big
value proposition of PHP, in addition to a good standard library.
Typescript has a completely different value proposition, and the
language itself is usually not the deciding factor, as there is so much
more to it.
Only through the deprecations and the type system does PHP even offer
some similar features as Typescript - like type checks and the
possibility of a static analyzer. If all these changes would not have
happened, people likely would argue even more that they had to switch to
Typescript, because of the missing type safety in PHP. Nowadays there
are even tools now like Rector that can help you automatically upgrade
your codebase - that is also a new value proposition. My projects were
affected by all the new warnings, deprecations etc. over the years, but
I found countless bugs because of those (and many bad choices - is
count($string) really what I wanted?). The language warning you when you
are likely doing something with little sense is a huge value proposition
- otherwise why are people using Typescript instead of Javascript?
It would be interesting to know why some people are having such huge
problems upgrading their applications, as I think those would often be
good stories with something to learn in them. So to the original poster
or other people with big problems when upgrading, writing a blog article
detailing what happened would be helpful to evaluate if the PHP project
could improve something, or even why something broke. And just as a
sidenote: I never have more things breaking than when trying to upgrade
a JS/TS-project, because of changes in NodeJS, because of slight breaks
in dependencies, etc. To me that clearly works better in PHP, but
experiences can differ.
It would be interesting to know why some people are having such huge
problems upgrading their applications, as I think those would often be
good stories with something to learn in them. So to the original poster
or other people with big problems when upgrading, writing a blog article
detailing what happened would be helpful to evaluate if the PHP project
could improve something, or even why something broke.
Would it really be considered helpful? When I or others like jrf who see
the potential problems try to warn about these issues here on Internals,
our concerns are generally ignored, or it's considered that we don't
want to allow PHP to move forward, or that we're simply scaremongering.
We aren't against PHP moving forward; we're not advocating that changes
and improvements shouldn't be made.
We are saying that they shouldn't be purely technical discussions about
implementation here on Internals, but there should also be consideration
for the impact on existing userland code. All too many of the changes
made in 8.0, 8.1 and 8.2 had no impact assessment, no consideration of
how much effort might be required for users to make the necessary
changes in their code. Thankfully, I've started seeing some effort again
to include a risk analysis or impact assessment in some of the more
recent RFCs.
And many of those RFCs work on the assumption that all existing PHP
codebases are adequately covered by unit tests to identify the points
where changes need to be made, and written well enough that any
designated fix will always work. But in the real world, that is rarely
the case, particularly with older codebases. Too often the RFCs seems to
assume the happy path; with testing for edge cases in developers
applications after release.
Nowadays there are even tools now like Rector that can help you
automatically
upgrade your codebase - that is also a new value proposition.
Tools like rector can help, particularly for developers that are
specifically upgrading from one PHP version to another; and rector is
certainly a game-changer there in the same way that Composer changed the
way that we build applications and manage dependencies. Where rector is
less useful is if we need to maintain the same codebase across multiple
PHP versions, which is the case for many libraries, as well as some of
the tools that we use for developing and testing.
--
Mark Baker
Unfortunately I couldn't find where, but I remember reading that PHP 7.2
deprecation of non-countable types was one of the biggest "busywork"
generator of the PHP 7 series. It made an extremely large impact at public
and private projects across the world for something with questionable
benefits.
I'm very thankful for fixes like this, it made us discover a lot of bugs in
a 20 year old product that we are still actively developing on.
I'd rather say that the roadblocks people are facing in upgrading legacy
projects are not specific to PHP 8, but rather a technical debt acquired
over the past 10-15 years. Even if nothing would change in PHP 8, people
would still complain about the upgrade because of unrelated reasons.Regards,
Kamil
I'm sorry for the double-answer but this snippet striked me a lot. I'm
quite curious to read a follow up on what you mean by unrelated reasons
here.
Suppose a parallel universe that code written in PHP 5.6 runs without any
changes in PHP 8.2. What unrelated changes would people have to not
upgrade? If the code runs exactly the same, there's no warnings converted
into exceptions that change code execution, no deprecations, no behavior
changes, what is it that people would complain about?
Or maybe when you wrote "Even if nothing would change in PHP 8" you meant
something different than what I interpreted?
Or maybe when you wrote "Even if nothing would change in PHP 8" you meant
something different than what I interpreted?
I meant things like refactoring, fixing bugs, updating dependencies.
Changes in code unrelated to changes in the language. When people leave
technical debt for later, the upgrade becomes more painful to them.
I wonder about this every time I hear this claim. What exactly changed in PHP
8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a
little more difficult because of some of the recent deprecations, but that's
still years ahead of us. So what's exactly driving people away from PHP 8?
Why is the adoption dwindling?
The change in null handling. We have a codebase that dates to 1998. It's fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that took almost a year due to the change in null handling. We have 40 XML and JSON APIs with various banks. Elements may or may not exist. The database, which is 45TB, has nulls all over it. And when it was all "upgraded" to run on PHP8 all we really got that was useful to us is two new string functions. And a codebase that now has ?? as every third line.
-Jeff
The change in null handling. We have a codebase that dates to 1998. It's
fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that
took almost a year due to the change in null handling. We have 40 XML and
JSON APIs with various banks. Elements may or may not exist. The database,
which is 45TB, has nulls all over it. And when it was all "upgraded" to run
on PHP8 all we really got that was useful to us is two new string
functions. And a codebase that now has ?? as every third line.
This is probably my biggest stylistic gripe with PHP 8+ just because of how
ubiquitous the "undefined array index" scenario is.
In JavaScript:
let obj = {};
obj['undefinedkey'] === undefined;
let str = `Welcome, ${obj['undefinedkey'] ?? 'Customer'}!`;
if( obj['undefinedkey'] || $obj['undefinedkey2'] ) doSomething();
In PHP:
$obj = [];
($obj['undefinedkey'] ?? null) === null;
$str = "Welcome, " . ($obj['undefinedkey'] ?? 'Customer') . "!";
if( ( $obj['undefinedkey'] ?? null) || ($obj['undefinedkey2'] ?? null) )
doSomething();
I wonder about this every time I hear this claim. What exactly changed
in PHP
8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be
a
little more difficult because of some of the recent deprecations, but
that's
still years ahead of us. So what's exactly driving people away from PHP
8?
Why is the adoption dwindling?The change in null handling. We have a codebase that dates to 1998. It's
fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that
took almost a year due to the change in null handling. We have 40 XML and
JSON APIs with various banks. Elements may or may not exist. The database,
which is 45TB, has nulls all over it. And when it was all "upgraded" to run
on PHP8 all we really got that was useful to us is two new string
functions. And a codebase that now has ?? as every third line.-Jeff
--
To unsubscribe, visit: https://www.php.net/unsub.php
I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of some of the recent deprecations, but that's still years ahead of us.
Most of the deprecations and changes do make sense, and while deprecating dynamic properties is going to be a pain, I think it's going to be worth it (like undefined variables), same with ${} string interpolation (better to be consistent); and I know it's been mentioned in this thread, but utf8_decode does get misused a lot (read the RFC as to why).
But I do not understand "Passing null to parameter # of type string is deprecated" specifically.
I should note that the other coercion/type tweaks that G.B.P (Girgias) is suggesting, and has partially implemented, do make sense:
https://github.com/Girgias/unify-typing-modes-rfc
And (fortunately) NULL coercion still works when concatenating NULL to a string, adding NULL to an integer, NULL being treated as false, etc.
One team of developers I know are still finding these issues well over a year later (they also introduce new code that trips it as well); two other teams specifically ignore this deprecation (far too many instances to "fix"), and one team is still to decide what they are going to do (annoyingly they are still using 7.4).
Even Rector gives up and uses (string) $var for every variable that's a non-nullable string, which can result in thousands of changes in a project (that's for the ~434 function arguments being checked; personally I'd have only gone with 335 of the ~997):
Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't using strict types, that's going to cause lots of random and unexpected problems.
Craig
PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it would have been voted down, and then used to justify the type error):
Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g.
has 4 different outputs between php 7.x and 8.x. From userland perspective, having <?php8 or <?php9 would make things a lot easier and more productive.
Regards
Thomas
Craig Francis craig@craigfrancis.co.uk hat am 10.04.2023 14:58 CEST geschrieben:
I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of some of the recent deprecations, but that's still years ahead of us.
Most of the deprecations and changes do make sense, and while deprecating dynamic properties is going to be a pain, I think it's going to be worth it (like undefined variables), same with ${} string interpolation (better to be consistent); and I know it's been mentioned in this thread, but
utf8_decodedoes get misused a lot (read the RFC as to why).But I do not understand "Passing null to parameter # of type string is deprecated" specifically.
I should note that the other coercion/type tweaks that G.B.P (Girgias) is suggesting, and has partially implemented, do make sense:
https://github.com/Girgias/unify-typing-modes-rfc
And (fortunately)
NULLcoercion still works when concatenatingNULLto a string, addingNULLto an integer,NULLbeing treated as false, etc.One team of developers I know are still finding these issues well over a year later (they also introduce new code that trips it as well); two other teams specifically ignore this deprecation (far too many instances to "fix"), and one team is still to decide what they are going to do (annoyingly they are still using 7.4).
Even Rector gives up and uses
(string) $varfor every variable that's a non-nullable string, which can result in thousands of changes in a project (that's for the ~434 function arguments being checked; personally I'd have only gone with 335 of the ~997):Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't using strict types, that's going to cause lots of random and unexpected problems.
Craig
PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it would have been voted down, and then used to justify the type error):
Hi
Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g.
has 4 different outputs between php 7.x and 8.x. From userland perspective, having <?php8 or <?php9 would make things a lot easier and more productive.
No, it has two different outputs, one for PHP 7, one for PHP 8.
It also has two different deprecation notices, one concerning the
behavioral change between PHP 7 and PHP 8 we're seeing and one
concerning an upcoming behavioral change with PHP 9.
However in all PHP versions the function call clearly is non-sense,
because 'null' clearly cannot be a substring of a string, as it is a
completely unrelated data type.
Best regards
Tim Düsterhus
I don't want to say that everything in old code bases makes sense, I just want to say that mixing null and empty string was quite common in the past, mostly coming from accessing undefined array keys. PHP has always been good to create new business value quickly. The problem now is that bringing all code into new standards does not bring new business value, so companies try to delay or refuse the upgrades as long as possible (also thanks to docker and others). Also many developers don't like upgrading code since it's either too boring or too challenging. The first thing done is mostly silencing deprecation messages, which makes the gap bigger when upgrading to the next major version.
So having support for multiple php versions inside one binary would be a great thing, same as modern web browsers still support html 4 even though html 5 is out for so many years.
Regards
Thomas
Tim Düsterhus tim@bastelstu.be hat am 10.04.2023 16:48 CEST geschrieben:
Hi
Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g.
has 4 different outputs between php 7.x and 8.x. From userland perspective, having <?php8 or <?php9 would make things a lot easier and more productive.
No, it has two different outputs, one for PHP 7, one for PHP 8.
It also has two different deprecation notices, one concerning the
behavioral change between PHP 7 and PHP 8 we're seeing and one
concerning an upcoming behavioral change with PHP 9.However in all PHP versions the function call clearly is non-sense,
because 'null' clearly cannot be a substring of a string, as it is a
completely unrelated data type.Best regards
Tim Düsterhus--
To unsubscribe, visit: https://www.php.net/unsub.php
So having support for multiple php versions inside one binary would be a great thing, same as modern web browsers still support html 4 even though html 5 is out for so many years.
As far as I'm aware, browsers have no specific support for HTML 4.
Arguably, they have no specific support for HTML 5, either. They (aim
to) implement the "HTML Living Standard", which has a carefully designed
parsing algorithm and three modes ("no-quirks", "quirks", and
"limited-quirks"), which standardise and emulate certain behaviours of
older browsers, not necessarily older specifications.
Certainly, web technologies like HTML + DOM, JS / ECMAScript, and CSS,
are good examples of carefully maintaining compatibility where possible,
and including features specifically to keep old websites working. But
that doesn't mean no feature is ever removed, and no default behaviour
ever changes. Nor will there be an ever-growing list of switches to go
back to what things looked like 10, 20, 30 years ago.
That's because maintaining extra behaviour is difficult - adding the
feature switch might be just a few lines of code, but it will multiply
a section of tests; and it will need to be re-implemented to pass those
tests every time the surrounding code is refactored, and accounted for
every time a related feature is added.
That might be worthwhile for one or two switches - HTML's "quirks" &
"limited-quirks", JS's "use strict" - but it doesn't scale, so it's
never going to replace the genuinely hard question of how to improve a
language for new code, while limiting pain for existing code.
Regards,
--
Rowan Tommins
[IMSoP]
On Mon, Apr 10, 2023 at 3:59 PM Craig Francis craig@craigfrancis.co.uk
wrote:
One team of developers I know are still finding these issues well over a
year later (they also introduce new code that trips it as well); two other
teams specifically ignore this deprecation (far too many instances to
"fix"), and one team is still to decide what they are going to do
(annoyingly they are still using 7.4).
How can they be finding those issues over a year later? Do they have pieces
of
completely untested code that has never been called in more than a year? If
so, they have
bigger problems than PHP deprecations. Otherwise, they should see the
deprecation
logs either on production or on CI. I highly doubt they're not collecting
any logs
from production, so they had more than a year to collect all the places
where a
deprecation is triggered and fix them.
Speaking of those that ignore them, well, I'm not
sure what the expectation is. Do they think the deprecation will simply go
away on
itself? Or do they expect the already small PHP team to infinitely support
their code,
sacrificing other developers' experience? Also, can you name an actively
developed
software product that introduced no breaking changes in the span of the
expected 10
years?
Besides, as mentioned before, it's likely that such projects are also using
at least some other 3rd party PHP dependencies, and those usually have a
shorter
BC lifespan than PHP and require more efforts to keep them up-to-date.
Again, is
the expectation here to infinitely keep the backwards-compatibility? If so,
why is
it that almost every dependency follows Semver specifically to manage
breaking
changes, and there are practically no examples of actually avoiding
breaking changes in
the long term?
But what's the point of starting a greenfield project in PHP while
Typescript is right there?
An angle that isn't discussed enough is the ease of writing extensions for
other languages compared to PHP. I've written PHP for 23 years, and I'm
increasingly looking to other languages because they either come with a
prewritten extension PHP doesn't have or because I can more easily hack one
together to wrap a library (example: a new DB client)
PHP has FFI but IMO it would benefit from further development. And the
benefits of native extensions will often be what's needed instead of FFI.
Peter
Hi Stephan
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.
No worries, this seems like the appropriate place.
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.
There's no such guarantee at the moment. Anything that is agreed upon
by the 2/3 majority of voters is subject to change.
Some of my projects run for 5 to 10 years, in one case even 20 years.
There are companies that offer extended lifecycle support for PHP
versions that have officially reached EOL (examples being Zend or
TuxCare). I'm not sure if those will get you to that 10 year mark.
Note however that deprecation notices alone should not keep you from
upgrading to a newer version, as they don't have any runtime effect
with a correct production configuration and thus aren't considered
breaking. We generally postpone larger breaking changes to major
versions. In general, I do agree that we could minimize breaking
changes more, and limit them to the things that actually provide a
tangible benefit.
Sadly, there's a conflict of interest here. There are people who want
to keep running their existing websites without having to make any
changes, and there are people who are using PHP daily and would like
to see the language evolve. We would like to satisfy both of these
groups but that is difficult when they are often directly opposed. I
do think that if we only manage to satisfy the former, PHP will
gradually become less and less significant. That would be sad.
Ilija
Hi Stephan
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.No worries, this seems like the appropriate place.
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.There's no such guarantee at the moment. Anything that is agreed upon
by the 2/3 majority of voters is subject to change.Some of my projects run for 5 to 10 years, in one case even 20 years.
There are companies that offer extended lifecycle support for PHP
versions that have officially reached EOL (examples being Zend or
TuxCare). I'm not sure if those will get you to that 10 year mark.
Note however that deprecation notices alone should not keep you from
upgrading to a newer version, as they don't have any runtime effect
with a correct production configuration and thus aren't considered
breaking. We generally postpone larger breaking changes to major
versions. In general, I do agree that we could minimize breaking
changes more, and limit them to the things that actually provide a
tangible benefit.
Thanks for mentioning the extended lifecycle support. I wasn't aware of
that. Looks like even some webhosters provide something similar so it
might even be an option for small customers (restaurants, etc.).
Sadly, there's a conflict of interest here. There are people who want
to keep running their existing websites without having to make any
changes, and there are people who are using PHP daily and would like
to see the language evolve. We would like to satisfy both of these
groups but that is difficult when they are often directly opposed. I
do think that if we only manage to satisfy the former, PHP will
gradually become less and less significant. That would be sad.
Yes, this seems to be the prevalent mindset people like to group
themselves into. I don't have any good answers about that but a few
languages seemed to have handled that rather well.
Fortran for one changed a lot since its inception while still being very
stable. And before the first one says that it's dead, a dinosaur or
whatever: I thought so as well before I worked at a super computing
center for a while (around 2010). There pretty much everything was
written in Fortran and still is as far as I can tell. The language gets
an update every 10 years or so and it's still a pretty good tool for
physicists and engineers to write high-performance simulations. With
Fortran 95 you can almost write Ruby-like code if you care about
readability. Not that physicist do that since they name everything
alpha, theta, phidash, etc. which doesn't help. Anyway, there might be
something interesting to learn from languages that navigated the same
problems before.
Disclaimer: I'm not that old but I'm curious how programming as a
discipline is done and changes in different fields and industries. So I
dabble in a lot of different things.
Happy programming
Stephan
Sadly, there's a conflict of interest here. There are people who want
to keep running their existing websites without having to make any
changes, and there are people who are using PHP daily and would like
to see the language evolve. We would like to satisfy both of these
groups but that is difficult when they are often directly opposed. I
do think that if we only manage to satisfy the former, PHP will
gradually become less and less significant. That would be sad.Ilija
That makes total sense to me. On the other hand, throwing the existing
community out and chasing after a new community puts PHP at a very delicate
spot. There's a large world out there that thinks PHP is still PHP 4. Of
the large group of PHP adopters that stayed with the language for the last
decade, a large set seem to have their interests neglected and are being
forced into greenfield/rewrite. If you've bet money on PHP 15 years ago and
you're now being forced by the language to stay behind or rewrite, what are
the odds that PHP will keep being the betting choice?
Here are my 2 cents:
The "dangerous" part of PHP upgrades is when you have more than one
server and since you can't migrate a distributed system atomically, it
often means that for a period of time, your code needs to support
multiple versions (and you probably always have to do this for
libraries). Personally, I've been bitten by small, undocumented, BC
breaks that get marked 'wontfix' once reported, because fixing it
after a release is considered a BC break. All I can do is facepalm
while I update the code to handle different versions of PHP.
I freakin love PHP, so I'm not going anywhere, but it would be amazing
if core devs contributed to Rector (or something like it) that allowed
you to run a simple tool to upgrade your code from "8.2 compatible"
code to "8.2 + 8.3 compatible code" and then to "8.3-only compatible"
code. The community does its best, but the core devs working on it
know about the undocumented bits and probably the most efficient
implementation. For all I know, you all are already doing this, and if
so, you should tell the world.
Cheers,
Rob
Sadly, there's a conflict of interest here. There are people who want
to keep running their existing websites without having to make any
changes, and there are people who are using PHP daily and would like
to see the language evolve. We would like to satisfy both of these
groups but that is difficult when they are often directly opposed. I
do think that if we only manage to satisfy the former, PHP will
gradually become less and less significant. That would be sad.Ilija
That makes total sense to me. On the other hand, throwing the existing
community out and chasing after a new community puts PHP at a very delicate
spot. There's a large world out there that thinks PHP is still PHP 4. Of
the large group of PHP adopters that stayed with the language for the last
decade, a large set seem to have their interests neglected and are being
forced into greenfield/rewrite. If you've bet money on PHP 15 years ago and
you're now being forced by the language to stay behind or rewrite, what are
the odds that PHP will keep being the betting choice?
On the other hand, throwing the existing
community out and chasing after a new community puts PHP at a very delicate
spot.
No. Stop. This is not what Ilija said at all. It is FUD to the point of disinformation, and is an insult to the hundreds of people that have worked, mostly on their own time, to give you the most popular web language in the world, for free.
There's a large world out there that thinks PHP is still PHP 4.
Most of them that I've met are not PHP developers. They're JS or Python or Ruby devs who like to hate on PHP as a way to build their own community cred.
now being forced by the language to stay behind or rewrite
This is BS. I have worked on a 20+ year old code base. It's BS. Stop spreading BS.
Perhaps the risk analyses et al that Mark Baker talked about would be more likely to happen if core devs weren't insulted on a regular basis by people making hyperbolic lies and trashing their existing efforts.
I've written about this before, just recently. Please read it twice before posting again and insulting the work of those who have given you a platform for your career, for free.
https://peakd.com/hive-168588/@crell/upgrading-php-upgrades
--Larry Garfield
No. Stop. This is not what Ilija said at all. It is FUD to the point of
disinformation, and is an insult to the hundreds of people that have
worked, mostly on their own time, to give you the most popular web language
in the world, for free.
I understand that you have misread my message as some kind of insult. I can
get 100% behind the "misinformation" aspect, so please inform me if you can.
There's a large world out there that thinks PHP is still PHP 4.
Most of them that I've met are not PHP developers. They're JS or Python
or Ruby devs who like to hate on PHP as a way to build their own community
cred.
Yes. And they're succeeding at luring the best PHP engineers I've met on my
career out of PHP.
now being forced by the language to stay behind or rewrite
This is BS. I have worked on a 20+ year old code base. It's BS. Stop
spreading BS.
Perhaps you'd like to read the rules and guidelines of participating in the
PHP Internals and would like a chance to reword this? I would be happy to
disregard this message and read a new one where you present your message
with more clarity.
Perhaps the risk analyses et al that Mark Baker talked about would be more
likely to happen if core devs weren't insulted on a regular basis by people
making hyperbolic lies and trashing their existing efforts.I've written about this before, just recently. Please read it twice
before posting again and insulting the work of those who have given you a
platform for your career, for free.
I'm sorry you feel that way. Whatever message you're trying to get across
has not reached me, at least. But I also know whatever message I'm trying
to get across will not reach you.
In fact, this is precisely the type of toxicity that habits Internals
during controversial discussions. While you have decided that I'm a
ungrateful enemy that wants to trash talk about volunteers work, I'm
actually here spending my time advocating for things that I believe could
improve on PHP out of pure selfish reasons: I don't want to leave PHP and I
don't want to be forced to take a NodeJS job, but the little bubble I live
in that's becoming the only way forward.
On Twitter you see a lot of folks advocating for more voices and
participation on Internals even if you don't have a vote. But when we come
here to participate this is how we're received?
No. Stop. This is not what Ilija said at all. It is FUD to the point of
disinformation, and is an insult to the hundreds of people that have
worked, mostly on their own time, to give you the most popular web language
in the world, for free.I understand that you have misread my message as some kind of insult. I can
get 100% behind the "misinformation" aspect, so please inform me if you can.There's a large world out there that thinks PHP is still PHP 4.
Most of them that I've met are not PHP developers. They're JS or Python
or Ruby devs who like to hate on PHP as a way to build their own community
cred.Yes. And they're succeeding at luring the best PHP engineers I've met on my
career out of PHP.
They'd be doing that regardless of what the engine fixes. If anything, their argument is easier if the engine never fixes old bad decisions.
now being forced by the language to stay behind or rewrite
This is BS. I have worked on a 20+ year old code base. It's BS. Stop
spreading BS.Perhaps you'd like to read the rules and guidelines of participating in the
PHP Internals and would like a chance to reword this? I would be happy to
disregard this message and read a new one where you present your message
with more clarity.
Perhaps you'd like to not insult the people you're trying to persuade. No one, literally no one, in all of the Internals community is "forcing" you or anyone else to "rewrite" your entire code base.
Asserting that is a lie. It is disinformation. And it makes it less likely that anything will change; I know multiple internals devs who are not in this thread, who have been doing the work of keeping PHP going and moving it forward (and I do not count myself among their number), who took one look at this thread and went "nope, not this crap again, not interested."
Perhaps the risk analyses et al that Mark Baker talked about would be more
likely to happen if core devs weren't insulted on a regular basis by people
making hyperbolic lies and trashing their existing efforts.I've written about this before, just recently. Please read it twice
before posting again and insulting the work of those who have given you a
platform for your career, for free.I'm sorry you feel that way. Whatever message you're trying to get across
has not reached me, at least. But I also know whatever message I'm trying
to get across will not reach you.In fact, this is precisely the type of toxicity that habits Internals
during controversial discussions. While you have decided that I'm a
ungrateful enemy that wants to trash talk about volunteers work, I'm
actually here spending my time advocating for things that I believe could
improve on PHP out of pure selfish reasons: I don't want to leave PHP and I
don't want to be forced to take a NodeJS job, but the little bubble I live
in that's becoming the only way forward.On Twitter you see a lot of folks advocating for more voices and
participation on Internals even if you don't have a vote. But when we come
here to participate this is how we're received?
Don't try with the guilt trip.
When more voices come on the list and make reasonable proposals? Sure, welcome.
When more voices come on the list and raise reasonable concerns? Sure, welcome.
When more voices come on the list and lie? No, that's not welcome.
The OP at the start of this thread sounded earnest, even if this is a well-deceased horse by now. The initial responses to him were reasonable. The hyperbole that a few people are tossing around is not.
Could internals do better on BC, to make upgrades easier? Yes! I have said so many times. I proposed several possible improvements in the blog post above. Mark Baker has focused on better risk analysis elsewhere in this thread, and that's fine. A more formal, standard way to measure the risk of a change would be a good thing. Let's discuss that.
Do you have an actionable, concrete proposal for how to let PHP continue to get rid of 20 year old bad ideas that make development worse for everyone, while minimizing the hassle for the most developers? If so, please share that instead of spreading nonsense about "have to rewrite everything." As soon as you get into that hyperbole, you lose all credibility and no one cares if you are raising valid concerns.
Let's discuss how specific changes could have been handled better, in a non-judgmental fashion, so that we can collectively do better on the next similar change.
Here, I'll even give you a concrete example: https://wiki.php.net/rfc/saner-inc-dec-operators
This is a good change to clean up an old buggy design. Let's suppose that we were 100% certain it would pass with 100% approval. However, if someone is doing something screwy and buggy it will change the behavior by making previously-kinda-working-but-definitely-buggy code throw a Warning, and later another oddball usage will throw a deprecation, and then eventually in PHP 9 a TypeError.
Again, let's assume there is no question it will happen. The question for you: What process for making it happen would you consider sufficiently BC-friendly? What timeline? What level of pre-review? What reasonable process would you propose that maximizes the ability of the language to remove its own design bugs while minimizing the hassle for responsible developers? (Responsible: They actually pay attention to upcoming changes and prepare for them in less than 7 years.)
I'm completely serious. We need to have that discussion. But what we always get instead if "you're forcing me to rewrite all my codez!" (because the person didn't bother fixing a known issue that's been a known-issue for literally a decade or more until the very last second). That actively harms PHP and actively harms our ability to improve the BC story.
Please help, not harm.
--Larry Garfield
Here, I'll even give you a concrete example:https://wiki.php.net/rfc/saner-inc-dec-operators
This is a good change to clean up an old buggy design. Let's suppose that we were 100% certain it would pass with 100% approval. However, if someone is doing something screwy and buggy it will change the behavior by making previously-kinda-working-but-definitely-buggy code throw a Warning, and later another oddball usage will throw a deprecation, and then eventually in PHP 9 a TypeError.
Perhaps not the best example. There's definitely some cases that need
cleaning up; but deprecating inc/dec for anything but numeric values is
IMO too extreme in what it proposes making it little more than syntactic
sugar for the += and -= operators, only working with numeric values.
https://wiki.php.net/rfc/saner-array-sum-product might be a better example.
--
Mark Baker
On Mon, Apr 10, 2023 at 7:03 PM Larry
Again, let's assume there is no question it will happen. The question for
you: What process for making it happen would you consider sufficiently
BC-friendly? What timeline? What level of pre-review? What reasonable
process would you propose that maximizes the ability of the language to
remove its own design bugs while minimizing the hassle for responsible
developers? (Responsible: They actually pay attention to upcoming changes
and prepare for them in less than 7 years.)
What I would consider sufficiently BC-friendly is having a cut-off. Any
code written by the previous generation (folks that are long gone or
retired by now) continue to work as it used to while I catch up in removing
it from production systems. If the code was written in 2010 or earlier and
uses $a++; with the expectation that it will result in "b", leave it as-is.
If the code was written in 2018 or earlier, feel free to break it.
Several discussions around this have happened, but unfortunately none
landed anywhere. Whether it be a new opening tag of <php8 or <php9 or a new
directive/edition. In fact, if we're talking about my opinion only (what
works for me personally), make this change behind the existing
strict_types=1. There's no "PHP 5 Era" code under my responsibility that
has strict_types enabled so if it were up to me, make every BC break you
want behind strict_types=1 but keep PHP with strict_types=0 running without
BC breaks for about 10 years.
When PHP libraries break BC, it often comes with options of 1) extend the
original class and override something 2) opt-in to old behavior 3) register
a callback that can be used to define the old behavior back in or 4) work
with an interface or 5) last resort to fork the library if taking the
maintenance burden is worth it. I don't have any of these options when PHP
breaks BC.
Yes, old PHP has some bad and weird behaviors. I don't like it, you don't
like it, nobody likes it. I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has been
written in an era that "best practices for PHP development" were not what
you and I know today.
Take PHP 7.2 deprecation of counting non-countable arguments. Could that
broken code have been taken out of PHP Core, made it available as a legacy
PHP extension and just kept alive for the foreseeable future? Can we have
an additional PHP extension that allows us to still pass null to
non-nullable internal function parameters? Something like php56_substr().
I don't mind if its BC breaks are opt-in or opt-out as long as we can have
a single cut-off and make it easier for us to keep running legacy code
until we succeed in decommissioning it.
In fact, if you wanted to deprecate readonly in PHP 8.3 because (as
you've said it), it's a broken behavior that prevents you to move forward
with asymmetric visibility or property accessors, I wouldn't care because
readonly was something introduced in a time that the code being written
using it has 100% test coverage and static analysers protecting it. It's
easier for me to deal with any BC breaks of PHP 7.1 or higher than it is to
deal with deprecations of PHP 5.6 or lower.
I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has been
written in an era that "best practices for PHP development" were not what
you and I know today.
I still do not understand why you're expecting the whole PHP project to put
in enormous efforts to keep the backwards compatibility and solve your
problems (temporarily) instead of you doing so. What's stopping you from
using the last supported PHP version by that codebase and fixing or, worst
case scenario, rewriting it if you wish, while on that (non latest) PHP
version? What causes the desperation to update to the latest PHP? Is it new
features or security fixes, or both?
I'm also curious to hear whether any participants in this thread do/did
support the PHP foundation in any tangible way :D
If you treat it like an LTS provider, perhaps it's time to pay up the LTS
support fees?
Marco Pivetta
https://mastodon.social/@ocramius
I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has
been
written in an era that "best practices for PHP development" were not what
you and I know today.I still do not understand why you're expecting the whole PHP project to put
in enormous efforts to keep the backwards compatibility and solve your
problems (temporarily) instead of you doing so. What's stopping you from
using the last supported PHP version by that codebase and fixing or, worst
case scenario, rewriting it if you wish, while on that (non latest) PHP
version? What causes the desperation to update to the latest PHP? Is it new
features or security fixes, or both?
What's meaningful in this sense?
I have a budget for supporting open source projects (back to my money v time point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS fees we pay elsewhere (even sometimes as a safety net) to the Foundation but believe that the money we give to projects is just that, a donation that the project can use as it sees fit, rather than the purchasing of a service as we do commercially.
Best wishes,
Matt
I'm also curious to hear whether any participants in this thread do/did
support the PHP foundation in any tangible way :DIf you treat it like an LTS provider, perhaps it's time to pay up the LTS
support fees?Marco Pivetta
https://mastodon.social/@ocramius
I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has
been
written in an era that "best practices for PHP development" were not what
you and I know today.I still do not understand why you're expecting the whole PHP project to put
in enormous efforts to keep the backwards compatibility and solve your
problems (temporarily) instead of you doing so. What's stopping you from
using the last supported PHP version by that codebase and fixing or, worst
case scenario, rewriting it if you wish, while on that (non latest) PHP
version? What causes the desperation to update to the latest PHP? Is it new
features or security fixes, or both?
Just to follow up on that, and going totally off topic, I was reading about thanks.dev the other day.
One of our concerns is that we can easily give money to top level projects or things we consciously add but how do you give it to all the dependencies and the thanks.dev approach seems a good idea (I have a separate problem in that our projects are rarely on GitHub or GitLab) but does anybody who would actually benefit from it have any thoughts on whether it would be good for them or not?
What's meaningful in this sense?
I have a budget for supporting open source projects (back to my money v time point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS fees we pay elsewhere (even sometimes as a safety net) to the Foundation but believe that the money we give to projects is just that, a donation that the project can use as it sees fit, rather than the purchasing of a service as we do commercially.
Best wishes,
Matt
I'm also curious to hear whether any participants in this thread do/did
support the PHP foundation in any tangible way :DIf you treat it like an LTS provider, perhaps it's time to pay up the LTS
support fees?Marco Pivetta
https://mastodon.social/@ocramius
I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has
been
written in an era that "best practices for PHP development" were not what
you and I know today.I still do not understand why you're expecting the whole PHP project to put
in enormous efforts to keep the backwards compatibility and solve your
problems (temporarily) instead of you doing so. What's stopping you from
using the last supported PHP version by that codebase and fixing or, worst
case scenario, rewriting it if you wish, while on that (non latest) PHP
version? What causes the desperation to update to the latest PHP? Is it new
features or security fixes, or both?
I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has
been
written in an era that "best practices for PHP development" were not what
you and I know today.I still do not understand why you're expecting the whole PHP project to
put in enormous efforts to keep the backwards compatibility and solve your
problems (temporarily) instead of you doing so. What's stopping you from
using the last supported PHP version by that codebase and fixing or, worst
case scenario, rewriting it if you wish, while on that (non latest) PHP
version? What causes the desperation to update to the latest PHP? Is it new
features or security fixes, or both?
I don't expect the whole PHP project to do anything. Let me start by
bringing up a quote:
[...] your thoughtful insight on how language changes [...] will help
shape proposals in a much more significant way.
Disclaimer: This quote is taken out of context, the original message can be
found here: https://externals.io/message/110936#110937
As I've mentioned here before, I've seen a few folks bring up the message
that I see on this quote as: Voting rights are not necessary to contribute
to PHP Internals. PHP is an extremely large ecosystem and bringing
community/user voices to internals can greatly help developers understand
how the language is being used and how proposals can be shaped to help
address concerns that are made aware. I'm not voicing my concerns in the
hopes of making my problems your problems and that the PHP core developers
should fix it for me. I have been going through a rewrite for the last 6
years and I expect to be done with it in the next 5. Every year we need to
go back to the legacy spaghetti and upgrade it for security reasons. It's
busywork and adds no real value to us. We still do it and we will keep
doing it no matter what. But in the course of doing so, I lost coworkers to
Typescript with a reasoning that it doesn't make sense to rewrite our
product in a language that will keep breaking the codebase constantly. I'm
not here to discuss the merits of their decision because if I 100% agreed
with that decision, I wouldn't be here, I would be long gone and developing
Typescript fulltime by now. But in my little bubble, losing highly talented
PHP developers to Typescript has been a recurring situation and that loss
of community members saddens me.
So if you could please read my message as "here's what has happened in a
small corner of the PHP community that is directly related to what OP has
mentioned at the start of the thread (PHP stability). Maybe this is not new
information to any of you here and there's nothing that can be improved on
it unless someone drops 8 digits of money on the PHP project. Maybe that is
a price that PHP has been willing to pay to keep on doing what it currently
is doing. Or maybe there are some interesting things that can be taken into
consideration. Do what you will with my participation. The only expectation
I had when I joined this discussion was respect and that was almost
completely met.
--
Marco Deleu
was something introduced in a time that the code being written using it has
100% test coverage and static analysers protecting it. It's easier for me to deal
with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations of
PHP 5.6 or lower.
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying.
-Jeff
was something introduced in a time that the code being written using it has
100% test coverage and static analysers protecting it. It's easier for me to deal
with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations of
PHP 5.6 or lower.Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying.
So turn off the deprecation warnings for now. They're just a heads up that behaviour is going to change in the future, with PHP 9.
I doubt you'd prefer not to be aware of the change well in advance.
cheers
Derick
So turn off the deprecation warnings for now. They're just a heads up that
behaviour is going to change in the future, with PHP 9.I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit.
It's only a tiny portion of the language changes, though, and I mention it just for awareness, as we are VERY appreciative of the work everyone puts into the PHP project. I know it's a thankless task.
-Jeff
So turn off the deprecation warnings for now. They're just a heads up that
behaviour is going to change in the future, with PHP 9.I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit.
Removing dynamic properties has multiple benefits - from avoiding
typos/mistakes (which before were completely silent) from being able to
refactor objects in PHP in general (after PHP9) to be more efficient.
The RFC (https://wiki.php.net/rfc/deprecate_dynamic_properties) details
those benefits quite well, if there were no benefits it would hardly
have passed. This is one of the no-brainer changes for me, as the
upgrade path with the attribute is so easy and there are so many benefits.
was something introduced in a time that the code being written using it
has
100% test coverage and static analysers protecting it. It's easier for
me to deal
with any BC breaks of PHP 7.1 or higher than it is to deal with
deprecations of
PHP 5.6 or lower.Essentially the same thing here. Removal of dynamic properties will be the
next big one for my team. It's the deprecations that hit huge swaths of
code without really offering much benefit that are annoying.-Jeff
You can add #[AllowDynamicProperties] to classes where you want to allow
dynamic properties.
You can add
#[AllowDynamicProperties]to classes where you want to allow
dynamic properties.
I don't think that will work in PHP 9?
Hi
You can add
#[AllowDynamicProperties]to classes where you want to allow
dynamic properties.I don't think that will work in PHP 9?
As per the corresponding RFC at
https://wiki.php.net/rfc/deprecate_dynamic_properties#proposal:
Classes marked with #[AllowDynamicProperties] as well as their children can continue using dynamic properties without deprecation or removal.
Best regards
Tim Düsterhus
You can add
#[AllowDynamicProperties]to classes where you want to
allow
dynamic properties.I don't think that will work in PHP 9?
--
To unsubscribe, visit: https://www.php.net/unsub.php
Please double-check the source before sending questions like that to the
list, since that information is easilly accessible:
https://wiki.php.net/rfc/deprecate_dynamic_properties
Nothing of the sort is happening. The attribute is specifically to mark
classes that can use dynamic properties going forward.
Please double-check the source before sending questions like that to the list, since that information is easilly accessible
Sorry, I'll refrain from asking stupid questions in the future.
On Tue, Apr 11, 2023 at 9:18 AM Robert Landers landers.robert@gmail.com
wrote:
You can add
#[AllowDynamicProperties]to classes where you want to
allow
dynamic properties.I don't think that will work in PHP 9?
In Niki's earliest draft, he wanted to completely remove dynamic properties
from default class handlers in 9.0, as this would simplify the most
common use-case for classes and objects and improve their runtime
efficiency. Even in this case, however, the stdClass specialization would
have dynamic properties implemented in a way which would allow an escape
hatch for user classes via extending stdClass.
We wound up with the attribute approach instead, which means that the logic
for dynamic properties, as well as the allocation overhead, still has to
exist in all userland classes. All approaches however, came with stdClass
working as expected out of the box, and a low-effort, forward-compatible
escape hatch for those rare cases where dynamic properties are needed on
custom classes.
This is because PHP's dedication to stability IS, AND REMAINS, steadfast
and fanatical.
-Sara
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying.
-Jeff
You can add #[AllowDynamicProperties] to classes where you want to allow dynamic properties.
Yes, we have a lot of classes. Also multiple versions of Zend framework that we backport to. However, I see in a subsequent email that this is in preparation for improvements, which makes it more tolerable.
-Jeff
Essentially the same thing here. Removal of dynamic properties will be the
next big one for my team. It's the deprecations that hit huge swaths of
code without really offering much benefit that are annoying.Yes, we have a lot of classes. Also multiple versions of Zend framework
that we backport to. However, I see in a subsequent email that this is in
preparation for improvements, which makes it more tolerable.
To clarify; Are you saying that you have a lot of classes which make use
of dynamic properties? A class where properties are predefined is
unimpacted by this. stdClass is also unimpacted (as it implicitly has
allowdynamicproperties). The only classes you should need to add the
attribute to are ones where you're using them, essentially, as typed
associative arrays.
I'm surprised if that's what you have, because it seems like a lot of extra
effort to give names to what are essentially anonymous structures. The
advantage of providing a name should be that you get to know what
properties will be present (and perhaps that the values therein are
validated or typed themselves).
Can you expand a bit more on your use-case?
-Sara
Can you expand a bit more on your use-case?
Here are some things I've deliberately used dynamic properties for:
-
development proxies (production uses compiled proxies) for remote
objects [can use attribute or magic functions] -
visitor pattern when hacking on parser packages [in PHP 9, "hacking"
will be more complex if underlying package doesn't support dynamic
properties] -
"tagging" objects [can use weak maps now]
-
deserialization of user-submitted types to a base class [can just
'decorate' a stdClass]
In brackets, I listed the 'solution' for avoiding dynamic properties,
but FWIW, having dynamic properties available made it far easier to
create 'POC-style' code that could be refactored/rewritten. I
personally never saw a bug resulting from dynamic properties, but I
might have just been lucky.
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying.
Yes, we have a lot of classes. Also multiple versions of Zend framework that we backport to. However, I see in a subsequent email that this is in preparation for improvements, which makes it more tolerable.
To clarify; Are you saying that you have a lot of classes which make use of dynamic properties? A class where properties are predefined is unimpacted by this. stdClass is also unimpacted (as it implicitly has allowdynamicproperties). The only classes you should need to add the attribute to are ones where you're using them, essentially, as typed associative arrays.
I'm surprised if that's what you have, because it seems like a lot of extra effort to give names to what are essentially anonymous structures. The advantage of providing a name should be that you get to know what properties will be present (and perhaps that the values therein are validated or typed themselves).
Can you expand a bit more on your use-case?
We have a lot of classes, a small portion of which use dynamic properties, but we do not necessarily know which ones do. It’s different than, for example, a change to the count function. We can search for all instances of “count” but not for dynamic properties. I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths. I’d probably summarize our use case for dynamic properties as “old codebase and dynamic properties were OK”. Our system was originally in Perl, so the initial dev team probably felt at home with dynamic properties coming from Perl objects.
But again, after reading others’ comments stating that this is part of an effort to improve some aspect of PHP classes, we can live with the change.
I was recently looking at the Perl 5.x repo and was surprised at the amount of activity. There may be some small takeaway (like, literally a small takeaway, not in the “small meaning big” sense) in how the 5.x community has seemingly flourished, especially considering the failure of Perl 6.
-Jeff (and I apologize for the mauled quoting... Outlook, annoying mailing lists since forever)
Can you expand a bit more on your use-case?
We have a lot of classes, a small portion of which use dynamic
properties, but we do not necessarily know which ones do. It’s
different than, for example, a change to the count function. We can
search for all instances of “count” but not for dynamic properties. I’m
unsure if it’s practical to run deprecations on in prod and our test
suite, although substantial, doesn’t cover all code paths.
Tools like PHPStan and Psalm can do a pretty good job of finding all dynamic property usage for you, without needing to write a test suite for it. They'll treat them as an error, but it should give you a good sense of where to add the attribute.
It won't be perfect, but it will probably catch the lion's share of them unless you're doing very dynamic things. ($this->{$foo[$bar]} = 5, or stuff like that.)
--Larry Garfield
Hi
I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths.
You should be able to enable deprecations in production and then check
the type of error within your error handler. If it'sE_DEPRECATEDthe
error goes into a separate log file / is sent to a separate error
collection endpoint and execution continues, whereas anyE_NOTICEor
E_WARNINGis converted to an Exception and execution is aborted.
Best regards
Tim Düsterhus
On Mon, Apr 10, 2023 at 7:03 PM Larry
Again, let's assume there is no question it will happen. The question for
you: What process for making it happen would you consider sufficiently
BC-friendly? What timeline? What level of pre-review? What reasonable
process would you propose that maximizes the ability of the language to
remove its own design bugs while minimizing the hassle for responsible
developers? (Responsible: They actually pay attention to upcoming changes
and prepare for them in less than 7 years.)What I would consider sufficiently BC-friendly is having a cut-off. Any
code written by the previous generation (folks that are long gone or
retired by now) continue to work as it used to while I catch up in removing
it from production systems. If the code was written in 2010 or earlier and
uses $a++; with the expectation that it will result in "b", leave it as-is.
If the code was written in 2018 or earlier, feel free to break it.Several discussions around this have happened, but unfortunately none
landed anywhere. Whether it be a new opening tag of <php8 or <php9 or a new
directive/edition. In fact, if we're talking about my opinion only (what
works for me personally), make this change behind the existing
strict_types=1. There's no "PHP 5 Era" code under my responsibility that
has strict_types enabled so if it were up to me, make every BC break you
want behind strict_types=1 but keep PHP with strict_types=0 running without
BC breaks for about 10 years.When PHP libraries break BC, it often comes with options of 1) extend the
original class and override something 2) opt-in to old behavior 3) register
a callback that can be used to define the old behavior back in or 4) work
with an interface or 5) last resort to fork the library if taking the
maintenance burden is worth it. I don't have any of these options when PHP
breaks BC.Yes, old PHP has some bad and weird behaviors. I don't like it, you don't
like it, nobody likes it. I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has been
written in an era that "best practices for PHP development" were not what
you and I know today.Take PHP 7.2 deprecation of counting non-countable arguments. Could that
broken code have been taken out of PHP Core, made it available as a legacy
PHP extension and just kept alive for the foreseeable future? Can we have
an additional PHP extension that allows us to still pass null to
non-nullable internal function parameters? Something like php56_substr().I don't mind if its BC breaks are opt-in or opt-out as long as we can have
a single cut-off and make it easier for us to keep running legacy code
until we succeed in decommissioning it.In fact, if you wanted to deprecate
readonlyin PHP 8.3 because (as
you've said it), it's a broken behavior that prevents you to move forward
with asymmetric visibility or property accessors, I wouldn't care because
readonly was something introduced in a time that the code being written
using it has 100% test coverage and static analysers protecting it. It's
easier for me to deal with any BC breaks of PHP 7.1 or higher than it is to
deal with deprecations of PHP 5.6 or lower.
Thank you, now that's a proposal that we can actually discuss.
That said, I don't think that strategy would be viable, for a couple of reasons.
-
It assumes a strong correlation between "code was written in <2010" and "the QA process is crap", and likewise between "code was written >2010" and "the QA process is pretty solid." I strongly suspect that correlation is a lot weaker than you make it out to be. The really-old public projects I know (I've worked on Drupal and TYPO3 cores personally, both of which are 20+ year old code bases) have pretty solid test coverage now, and ample QA processes around them. They're possibly tedious to update for deprecations et al, but not per se hard. In contrast, I now work with some 7.x-era Laravel projects that, well, "get the QA tooling out of the stone age" was the first task I took on when I joined the company because they desperately needed it. I don't think "it's newer so the QA safety net is in place" is a safe assumption.
-
The vast majority of issues that need to be fixed are the old stuff; most are from PHP 4 or PHP 3, so we're talking pre-2005. The features introduced from 5.3 onward are, for the most part, pretty reasonable. (Not perfect, but way way better than the PHP 3-era stuff.) So "you can only clean up recent messes" translates to "you can never clean up a mess."
-
There can absolutely be code written in 2020 that relies on the current behavior of array_sum, or $string++, or passing null to
strlen(). Some of it has been mentioned in this thread. So "only old code relies on old, bad language design decisions" is not really a safe statement, either. We could say "well those devs should have known better," but... in most cases the code from 2005-2010 was also written by devs who "should have known better," as many of these issues were known-problematic even then. (Dynamic properties, for instance, have been not-recommended since at least 5.2, if not earlier.) -
It doesn't answer the question of when it is OK to start fixing the old issues. "When I'm done cleaning up the mess I inherited" is not a metric that Internals can really work with, but locking in "bad design decisions from before 2010 are locked in forever, just in case, but we can correct stuff after that without warning" is not really sustainable.
-
Different running "modes" have been discussed several times. Usually they come back to "if we were to do it, declare statements are the best mechanism." But they also almost always run into "every declare statement means we have to add a bunch of conditionals in the engine or stdlib to check it, which is a lot of complexity to maintain." And those are multiplicative, so if, eg, we added declare(allow_dyn_props=1), declare(allow_null_string=1), and declare(modern_numeric_strings=1), in addition to the existing strict_types, that's 222*2 = 16 possible combinations of run modes. Regardless of what the default values are, just thinking about the number of test cases that would need to be written for that makes me sweat. And that's before we even get into bifurcating PHP into multiple incompatible rulesets that make it hard for anyone to even learn how to use PHP.
If you want to polyfill old core stdlib function behavior, there might be a way to be extra tricksy with namespaces and autoloading (if that passes) to make something work, but that sounds unreliable. The real answer here would be the old runkit extension, but most people who know of that are afraid of it, because they know exactly how much confusion that could cause. ;-)
If the stdlib were written in PHP, not C, as has been suggested a few times, that might open up other options. I've not thought that through entirely. That's still not at the point that it wouldn't have a performance impact to do, though, which is why there's been no serious attempt at it.
--Larry Garfield
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller stephan.soller@helionweb.de
wrote:
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.
I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.
however years of ignoring deprecation notices (very few were introduced
right before 8.0).
Most of them could have been fixed within a couple of hours in any code
base, if they had tests.
I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.
best,
Pierre
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller stephan.soller@helionweb.de
wrote: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.I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.best,
Pierre
Hello!
I also want to add that PHP is purely developed by open-source contributor
efforts who are limited in their numbers and not a lot of them are getting
compensated for it (exceptions being specific people working for companies
who have a vested interest in PHP development like JetBrains, hosting
giants and some others. And now PHP Foundation is there to help people get
paid for their crucial roles in PHP project and their dedicated time).
You also have a world on your hands that is changing - everywhere you look
things are going for a more typed approach. That's what developers of today
expect. That's the reality of how modern libraries are developed and old
libraries have been actively migrating to strict type code bases. This code
quality improvement absolutely takes a huge load off those developers'
shoulders. I'm seeing libraries out there now that basically require PHP
8.1 as a minimum because Enums are all the rage and almost half the
libraries I use have introduced them in their code in the latest versions
and authors just flat-out tell you "use the older version of the lib or
update your project" (and I have at least 7 of them in my code already and
that project will never run on anything lower than 8.2). Some of the
biggest libraries out there have fully adopted SemVer and will bump the
minimal PHP version quite aggressively. And will tell you to pay for
commercial support or deal with it on your own. And now the Union types are
coming and I expect that to get adopted at a rapid pace by everyone and
their dog.
Just as owning your own house means you need to do the upkeep on a yearly
basis or it will become a mess, the same is with code and not maintaining
it - eventually, the roof will cave in and the costs of fixing it all will
skyrocket. And, frankly, this is the feeling I get from a lot of this
thread - the roof has collapsed and people are put into impossible
positions of "no, you can't have the time or resources to update the
project to the new PHP version, here are 20 KPI's for the next 3 months you
need to hit". The codebase was run on a credit of "this will be fixed down
the line". Well, the debt collectors now what their debt, their late fees
and lawyers want their slice of the pie.
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
I also want to add that PHP is purely developed by open-source contributor
efforts who are limited in their numbers and not a lot of them are getting
compensated for it (exceptions being specific people working for companies
who have a vested interest in PHP development like JetBrains, hosting
giants and some others. And now PHP Foundation is there to help people get
paid for their crucial roles in PHP project and their dedicated time).
Yes we know, and we're very grateful; but that doesn't mean we should be
unquestioningly grateful!
And some of us are also open-source contributors, not getting
compensated for it. We understand; and just as I try to take a
professional approach to my OS contributions, and assess the impact of
any change that may affect bc, I hope that PHP Internals does the same,
but I don't often see that. So am I expected to stay silent when I see
potential problems with bc breaks because I should just be grateful?
You also have a world on your hands that is changing - everywhere you look
things are going for a more typed approach. That's what developers of today
expect. That's the reality of how modern libraries are developed and old
libraries have been actively migrating to strict type code bases. This code
quality improvement absolutely takes a huge load off those developers'
shoulders. I'm seeing libraries out there now that basically require PHP
8.1 as a minimum because Enums are all the rage and almost half the
libraries I use have introduced them in their code in the latest versions
and authors just flat-out tell you "use the older version of the lib or
update your project" (and I have at least 7 of them in my code already and
that project will never run on anything lower than 8.2). Some of the
biggest libraries out there have fully adopted SemVer and will bump the
minimal PHP version quite aggressively. And will tell you to pay for
commercial support or deal with it on your own. And now the Union types are
coming and I expect that to get adopted at a rapid pace by everyone and
their dog.
Yes it is changing, but at different speeds in different companies.
Changes aren't being adopted at that rapid pace by everyone and their
dog, that's the reality.
Just as owning your own house means you need to do the upkeep on a yearly
basis or it will become a mess, the same is with code and not maintaining
it - eventually, the roof will cave in and the costs of fixing it all will
skyrocket. And, frankly, this is the feeling I get from a lot of this
thread - the roof has collapsed and people are put into impossible
positions of "no, you can't have the time or resources to update the
project to the new PHP version, here are 20 KPI's for the next 3 months you
need to hit". The codebase was run on a credit of "this will be fixed down
the line". Well, the debt collectors now what their debt, their late fees
and lawyers want their slice of the pie.
Do you think we're unaware of that! But you're suggesting that anybody
that isn't using the latest shiny release should be treated as though
they don't exist. They're not your problem, so forget about them. Many
of those developers would love to upgrade to the latest shiny release,
but that isn't always an option every November; that run-up to Christmas
can often be the busiest time of year for those developers, the time
when they are least in a position to go through an upgrade.
Telling them that the debt collectors and lawyers are here isn't going
to help them when the people that pay them so they can eat and have a
roof over their heads and care for their families is a slap in the face
to them when they are torn between business demands and wanting to do
technical upgrades.
And the attitude of some here on PHP Internals that we should just
ignore those who can't develop in greenfield environments using the
latest shiny, or that it should just be a simple upgrade step from last
version to current release... that's the equivalent of having unit tests
that only test the happy path.
--
Mark Baker
I also want to add that PHP is purely developed by open-source
contributor
efforts who are limited in their numbers and not a lot of them are
getting
compensated for it (exceptions being specific people working for
companies
who have a vested interest in PHP development like JetBrains, hosting
giants and some others. And now PHP Foundation is there to help people
get
paid for their crucial roles in PHP project and their dedicated time).Yes we know, and we're very grateful; but that doesn't mean we should be
unquestioningly grateful!And some of us are also open-source contributors, not getting
compensated for it. We understand; and just as I try to take a
professional approach to my OS contributions, and assess the impact of
any change that may affect bc, I hope that PHP Internals does the same,
but I don't often see that. So am I expected to stay silent when I see
potential problems with bc breaks because I should just be grateful?
Almost all other languages have deep pockets behind them one way or the
other. Frankly, they can afford it. PHP has no such option. So, in some
way, yes, sometimes you just have to take the loss and move on. PHP has to
prioritize the resources and relies on what people are interested in doing
for the project. Historically PHP just can't maintain lots of legacy stuff,
nor have long LTS releases - that's why there are only 3 versions of the
engine ever supported at the same time.
You also have a world on your hands that is changing - everywhere you
look
things are going for a more typed approach. That's what developers of
today
expect. That's the reality of how modern libraries are developed and old
libraries have been actively migrating to strict type code bases. This
code
quality improvement absolutely takes a huge load off those developers'
shoulders. I'm seeing libraries out there now that basically require PHP
8.1 as a minimum because Enums are all the rage and almost half the
libraries I use have introduced them in their code in the latest versions
and authors just flat-out tell you "use the older version of the lib or
update your project" (and I have at least 7 of them in my code already
and
that project will never run on anything lower than 8.2). Some of the
biggest libraries out there have fully adopted SemVer and will bump the
minimal PHP version quite aggressively. And will tell you to pay for
commercial support or deal with it on your own. And now the Union types
are
coming and I expect that to get adopted at a rapid pace by everyone and
their dog.Yes it is changing, but at different speeds in different companies.
Changes aren't being adopted at that rapid pace by everyone and their
dog, that's the reality.
This is business. Adapt or be swallowed by competitors. This really has
nothing to do with language development. 2 decades is enough for a
commercial entity to realise something needs to be done about the code base.
Speaking of competition - PHP needs to move forward at a pace where it
stays competitive with other languages too. The project has already
stumbled once, that's why the RFC process and yearly release cycle was
born. Because that thread was identified and people decided to do something
about it.
Just as owning your own house means you need to do the upkeep on a yearly
basis or it will become a mess, the same is with code and not maintaining
it - eventually, the roof will cave in and the costs of fixing it all
will
skyrocket. And, frankly, this is the feeling I get from a lot of this
thread - the roof has collapsed and people are put into impossible
positions of "no, you can't have the time or resources to update the
project to the new PHP version, here are 20 KPI's for the next 3 months
you
need to hit". The codebase was run on a credit of "this will be fixed
down
the line". Well, the debt collectors now what their debt, their late fees
and lawyers want their slice of the pie.Do you think we're unaware of that! But you're suggesting that anybody
that isn't using the latest shiny release should be treated as though
they don't exist. They're not your problem, so forget about them. Many
of those developers would love to upgrade to the latest shiny release,
but that isn't always an option every November; that run-up to Christmas
can often be the busiest time of year for those developers, the time
when they are least in a position to go through an upgrade.
PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the
code base in question is never going to keep up with PHP even if it does 1
release every 2 years. The result will be the same.
In my case, on multiple occasions, the management just decided to sunset
the old systems and just build new once on modern code bases with modern
frameworks, libraries and using all those bells and whistles like Psalm,
phpstan, cs-fixer, run modern development practices. Some people left, new
people got hired. Business moved on to have far more sustainable software
on their hands that underpins it's whole existence. Most clients I worked
for who clung to their old systems at this point are all defunct. Because
competitors just ate them up eventually.
Telling them that the debt collectors and lawyers are here isn't going
to help them when the people that pay them so they can eat and have a
roof over their heads and care for their families is a slap in the face
to them when they are torn between business demands and wanting to do
technical upgrades.
The point I was making is that at that moment it's too late to do anything.
That's when you close the business and hope you are not in the red.
And the attitude of some here on PHP Internals that we should just
ignore those who can't develop in greenfield environments using the
latest shiny, or that it should just be a simple upgrade step from last
version to current release... that's the equivalent of having unit tests
that only test the happy path.
In my opinion, it's not the job of the internals developers to solve legacy
system issues. They are developing a language, they are making sure
deprecations are issued well in advance, sometimes through multiple
versions and only then the feature is completely removed or made a full-on
error.
Why a PHP language developer should care about a commercial company having
a 20-year-old legacy system that has no resources to upkeep it's systems? I
mean even Microsoft does not care enough and are sunsetting their Windows
support even for customers who pay them literal bags of money and beg them
to continue. But they still cut their losses because at some point it makes
no damn sense for any amount of money.
--
Mark Baker--
To unsubscribe, visit: https://www.php.net/unsub.php
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
Yes we know, and we're very grateful; but that doesn't mean we should be
unquestioningly grateful!And some of us are also open-source contributors, not getting
compensated for it. We understand; and just as I try to take a
professional approach to my OS contributions, and assess the impact of
any change that may affect bc, I hope that PHP Internals does the same,
but I don't often see that. So am I expected to stay silent when I see
potential problems with bc breaks because I should just be grateful?Almost all other languages have deep pockets behind them one way or the
other. Frankly, they can afford it. PHP has no such option. So, in some
way, yes, sometimes you just have to take the loss and move on. PHP has to
prioritize the resources and relies on what people are interested in doing
for the project. Historically PHP just can't maintain lots of legacy stuff,
nor have long LTS releases - that's why there are only 3 versions of the
engine ever supported at the same time.
That does not mean that I should stay silent when I see problems; nor do
I intend to.
This is business. Adapt or be swallowed by competitors. This really has
nothing to do with language development. 2 decades is enough for a
commercial entity to realise something needs to be done about the code base.
Speaking of competition - PHP needs to move forward at a pace where it
stays competitive with other languages too. The project has already
stumbled once, that's why the RFC process and yearly release cycle was
born. Because that thread was identified and people decided to do something
about it.
I've not mentioned 20 years; but business application should have a
lifespan longer than a mayfly. Even 3 years feels too short for
companies that have a lot of apps that need to be maintained alongside
new development work. Not every company has enough developers for
dedicated teams to handle upgrade work full time.
PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the
code base in question is never going to keep up with PHP even if it does 1
release every 2 years. The result will be the same.
In my case, on multiple occasions, the management just decided to sunset
the old systems and just build new once on modern code bases with modern
frameworks, libraries and using all those bells and whistles like Psalm,
phpstan, cs-fixer, run modern development practices. Some people left, new
people got hired. Business moved on to have far more sustainable software
on their hands that underpins it's whole existence. Most clients I worked
for who clung to their old systems at this point are all defunct. Because
competitors just ate them up eventually.
Rewriting any system from scratch can be a major undertaking (I do know,
I've done this myself, and it took a team of 6 people over 8 month in
the most recent case). It isn't the type of undertaking that can be
taken without considerable investment. Yes, the new system was written
with all the bells and whistles; but upgrades still take time and
investment, and there's still the demand for new features. No companies
but the very biggest can indulge in that on a regular basis: developers
are there to add value with new features, not just staving off technical
debt.
Telling them that the debt collectors and lawyers are here isn't going
to help them when the people that pay them so they can eat and have a
roof over their heads and care for their families is a slap in the face
to them when they are torn between business demands and wanting to do
technical upgrades.The point I was making is that at that moment it's too late to do anything.
That's when you close the business and hope you are not in the red.
And that's tough on the developers that have been struggling with those
legacy debt issues alongside trying to keep a system running and making
money for their employer. When the business closes, it's the developers
that suffer, not the business.
Again, I'll re-iterate. Not all developers are working on shiny
greenfield projects, and they do have to balance upgrades with the new
work that the business is demanding. And not all developers are
freelance who can just walk away from companies that run legacy code,
and walk into new jobs with the latest shiny, latest tooling, and latest
processes.
And the attitude of some here on PHP Internals that we should just
ignore those who can't develop in greenfield environments using the
latest shiny, or that it should just be a simple upgrade step from last
version to current release... that's the equivalent of having unit tests
that only test the happy path.In my opinion, it's not the job of the internals developers to solve legacy
system issues. They are developing a language, they are making sure
deprecations are issued well in advance, sometimes through multiple
versions and only then the feature is completely removed or made a full-on
error.
Why a PHP language developer should care about a commercial company having
a 20-year-old legacy system that has no resources to upkeep it's systems?
Again with the 20 years. And when did I suggest that should be the role
of internals? BUT, the affect of internals changes on legacy code
shouldn't simply be ignored; where appropriate, upgrade
paths/recommendations should be provided, and the edge cases of those
changes should be considered. A small change to core code might have
minimal benefit; but could still create hours of extra upgrade work for
millions of developers around the world.
"they are making sure deprecations are issued well in advance, sometimes
through multiple versions and only then the feature is completely
removed or made a full-on error"
I do wish that this was always the case!
--
Mark Baker
Yes we know, and we're very grateful; but that doesn't mean we should be
unquestioningly grateful!And some of us are also open-source contributors, not getting
compensated for it. We understand; and just as I try to take a
professional approach to my OS contributions, and assess the impact of
any change that may affect bc, I hope that PHP Internals does the same,
but I don't often see that. So am I expected to stay silent when I see
potential problems with bc breaks because I should just be grateful?Almost all other languages have deep pockets behind them one way or the
other. Frankly, they can afford it. PHP has no such option. So, in some
way, yes, sometimes you just have to take the loss and move on. PHP has
to
prioritize the resources and relies on what people are interested in
doing
for the project. Historically PHP just can't maintain lots of legacy
stuff,
nor have long LTS releases - that's why there are only 3 versions of the
engine ever supported at the same time.That does not mean that I should stay silent when I see problems; nor do
I intend to.
Sure, but I would suggest picking the battles carefully. Resources are one
of the major problems here and getting new core devs on board is tough as
it is. As cliche as it sounds, we all should choose our words carefully.
God knows this list has a poor track record over the decades with making
newcomers feel comfortable :D But that's offtopic.
This is business. Adapt or be swallowed by competitors. This really has
nothing to do with language development. 2 decades is enough for a
commercial entity to realise something needs to be done about the code
base.
Speaking of competition - PHP needs to move forward at a pace where it
stays competitive with other languages too. The project has already
stumbled once, that's why the RFC process and yearly release cycle was
born. Because that thread was identified and people decided to do
something
about it.I've not mentioned 20 years; but business application should have a
lifespan longer than a mayfly. Even 3 years feels too short for
companies that have a lot of apps that need to be maintained alongside
new development work. Not every company has enough developers for
dedicated teams to handle upgrade work full time.
Well, we were given an example for discussion a real-life application
that's 20 years old. So I have been referring to that case.
As someone who dabbles in business, I see this a lot of the time when
company owners just decide to get a new 100k car instead of investing in
their business a bit, so it can survive the next 5 years. Personally, I
don' think a company that can't even upkeep it's own systems should be a
company that survives. It's better to have a new better company to take
it's place.
PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the
code base in question is never going to keep up with PHP even if it does
1
release every 2 years. The result will be the same.
In my case, on multiple occasions, the management just decided to sunset
the old systems and just build new once on modern code bases with modern
frameworks, libraries and using all those bells and whistles like Psalm,
phpstan, cs-fixer, run modern development practices. Some people left,
new
people got hired. Business moved on to have far more sustainable software
on their hands that underpins it's whole existence. Most clients I worked
for who clung to their old systems at this point are all defunct. Because
competitors just ate them up eventually.Rewriting any system from scratch can be a major undertaking (I do know,
I've done this myself, and it took a team of 6 people over 8 month in
the most recent case). It isn't the type of undertaking that can be
taken without considerable investment. Yes, the new system was written
with all the bells and whistles; but upgrades still take time and
investment, and there's still the demand for new features. No companies
but the very biggest can indulge in that on a regular basis: developers
are there to add value with new features, not just staving off technical
debt.
Yes, yes it is. But it also can usually be done in chunks - most systems
only seem like monoliths, but they aren't really.
I've literally headed a re-write project with a team of 4 at a company that
was barely 20 people total. So I will never take the argument "only big
companies can do that" as a valid one. If anything, bigger companies have a
far more higher failure rate because of bureaucracy, internal politics and
your typical corporate backstabbing.
Telling them that the debt collectors and lawyers are here isn't going
to help them when the people that pay them so they can eat and have a
roof over their heads and care for their families is a slap in the face
to them when they are torn between business demands and wanting to do
technical upgrades.The point I was making is that at that moment it's too late to do
anything.
That's when you close the business and hope you are not in the red.And that's tough on the developers that have been struggling with those
legacy debt issues alongside trying to keep a system running and making
money for their employer. When the business closes, it's the developers
that suffer, not the business.
That's the job. And developers really need to learn how to say "no" to
stakeholders instead of patching the Frankenstein for the 100's time making
things 1000 times worse. And then get eventually fired because you can't
keep up with the workload due to how bad the code is, so everything you
touch - breaks.
Again, I'll re-iterate. Not all developers are working on shiny
greenfield projects, and they do have to balance upgrades with the new
work that the business is demanding. And not all developers are
freelance who can just walk away from companies that run legacy code,
and walk into new jobs with the latest shiny, latest tooling, and latest
processes.
It's not about being new and shiny, it's about having reasonable processes
in the company and understanding that apps need upkeep. Worked plenty of
jobs that were 3-4 versions behind on their PHP, but there were always
efforts to update in the background as a matter of your daily job. Sure, I
learned just not to take the jobs that were stuck in legacy without any
prospects of improvement. I just know better (and they never pay even
decently) :)
And the attitude of some here on PHP Internals that we should just
ignore those who can't develop in greenfield environments using the
latest shiny, or that it should just be a simple upgrade step from last
version to current release... that's the equivalent of having unit tests
that only test the happy path.In my opinion, it's not the job of the internals developers to solve
legacy
system issues. They are developing a language, they are making sure
deprecations are issued well in advance, sometimes through multiple
versions and only then the feature is completely removed or made a
full-on
error.
Why a PHP language developer should care about a commercial company
having
a 20-year-old legacy system that has no resources to upkeep it's systems?Again with the 20 years. And when did I suggest that should be the role
of internals? BUT, the affect of internals changes on legacy code
shouldn't simply be ignored; where appropriate, upgrade
paths/recommendations should be provided, and the edge cases of those
changes should be considered. A small change to core code might have
minimal benefit; but could still create hours of extra upgrade work for
millions of developers around the world."they are making sure deprecations are issued well in advance, sometimes
through multiple versions and only then the feature is completely
removed or made a full-on error"I do wish that this was always the case!
Has been since the RFC process got introduced. Maybe one or two missteps
along the line that everybody learned from, but it really hasn't been an
issue for a long time now. Every RFC that needs it ends up considering and
implementing a depreciation period.
--
Mark Baker--
To unsubscribe, visit: https://www.php.net/unsub.php
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
I fully understand your point, having more tests is the best thing to do. Unfortunately many old code bases are not written to be tested easily. There is excessive inheritence, traits, reflection, globals, static calls, missing DI, magic functions, feature flags, database dependancies (e.g. 1 request reads 40 tables with 500 queries), library/framework dependancies (some unsupported, unmaintained, deprecated, etc.). So people spend a few months to get the coverage from 10 percent to 20 or 30 percent and the problems are still the same.
My point is that every hour being spend on old code is one hour less that can be spend on writing newer code, being better tested, following newer standards, etc.
So having language levels would make things a lot easier. There are many more things that should be deprecated and removed, but cannot be done now due to BC breaks and the risks for negative votings on the rfcs.
With language levels like <?php8, <?php9, old and new code can be executed together without making bigger changes to the old code. But I also understand the amount of work and increased complexity this would bring to the core development.
Regards
Thomas
Pierre Joye pierre.php@gmail.com hat am 10.04.2023 18:17 CEST geschrieben:
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller stephan.soller@helionweb.de
wrote: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.I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.best,
Pierre
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller stephan.soller@helionweb.de
wrote: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.I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.best,
Pierre
I resent the sentiment of "if your code or development process was exactly
like mine you wouldn't be here complaining" and I believe nobody is asking
PHP to freeze. Not everyone has the ability to fix every deprecation within
a couple of hours and not everyone has tests. Yes, we get it, it's common
knowledge nowadays that code without test is unmanageable, but if you
inherited a 15 year old codebase developed by multiple developers in a
start-up mentality producing code faster than they could actually plan for
and with no tests, its going to take some time to clean that up and if I
take longer than you would, does it mean I matter less as a PHP user?
PHP 8 is pretty great to work with and a lot better than previous versions,
but there was no opt-in aspect to a lot of PHP breakages. All that we're
asking here is for a bit more forgiveness to existing code that was
developed 2 decades ago by a complete different generation and still need
to run today while we clean it up.
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <stephan.soller@helionweb.de
wrote:
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.I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.best,
PierreI resent the sentiment of "if your code or development process was exactly
like mine you wouldn't be here complaining" and I believe nobody is asking
PHP to freeze. Not everyone has the ability to fix every deprecation within
a couple of hours and not everyone has tests. Yes, we get it, it's common
knowledge nowadays that code without test is unmanageable, but if you
inherited a 15 year old codebase developed by multiple developers in a
start-up mentality producing code faster than they could actually plan for
and with no tests, its going to take some time to clean that up and if I
take longer than you would, does it mean I matter less as a PHP user?PHP 8 is pretty great to work with and a lot better than previous versions,
but there was no opt-in aspect to a lot of PHP breakages. All that we're
asking here is for a bit more forgiveness to existing code that was
developed 2 decades ago by a complete different generation and still need
to run today while we clean it up.
Hello Deleu, I want to highlight your response specifically, because you
blame the wrong people here.
This is the failure of the business owner to plan accordingly and ignore
all the warnings for years and decades. That is if any developer raised any
concerns lately, which I also have seen quite a bit when "yes man" just
shove code into the meatgrinder for a year or two and then just move to the
next job: "It's not my problem, the next guy will deal with this". And that
feeds the vicious cycle, and the owner is either oblivious or does not
understand the implications because "well, it works, it generates money" at
the moment right until that plane hits the ground and things blow up.
I've handled a big legacy project, did major updates to it, seen how an
effort of 1 month of my time to drag it into the modern day paid off over
the next 6 months by picking up development speed by 3x with the same team
of 5 people + me. In 1 year we started to literally take away clients from
our competitors who could not keep up with us and we had a literal line of
clients to onboard, we had to scale our sales team 3x and had a backlog of
6 months still. All stemmed from a single decision "I will tackle this, we
need it to update to newer PHP". Business owners were really stoked that
they actually listened to developers.
You cannot expect to run code that was written 2 decades ago without major
updates on modern language versions. It's not possible for almost any
language that is being actively developed. Think laterally - instead of
hand-fixing every null check out there, introduce a library that can handle
data structures and handle the nulls for you en mass. Isolate the internals
and just pass already sanitized values into it. Suddenly you cut off like
90% of the needed fixes that prevent you from running your code. It's still
needs fixing, but at least you give it good data to start with, so it does
not error out.
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <
stephan.soller@helionweb.de>
wrote: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.I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.best,
PierreI resent the sentiment of "if your code or development process was exactly
like mine you wouldn't be here complaining" and I believe nobody is asking
PHP to freeze. Not everyone has the ability to fix every deprecation
within
a couple of hours and not everyone has tests. Yes, we get it, it's common
knowledge nowadays that code without test is unmanageable, but if you
inherited a 15 year old codebase developed by multiple developers in a
start-up mentality producing code faster than they could actually plan for
and with no tests, its going to take some time to clean that up and if I
take longer than you would, does it mean I matter less as a PHP user?PHP 8 is pretty great to work with and a lot better than previous
versions,
but there was no opt-in aspect to a lot of PHP breakages. All that we're
asking here is for a bit more forgiveness to existing code that was
developed 2 decades ago by a complete different generation and still need
to run today while we clean it up.Hello Deleu, I want to highlight your response specifically, because you
blame the wrong people here.
This is the failure of the business owner to plan accordingly and ignore
all the warnings for years and decades. That is if any developer raised any
concerns lately, which I also have seen quite a bit when "yes man" just
shove code into the meatgrinder for a year or two and then just move to the
next job: "It's not my problem, the next guy will deal with this". And that
feeds the vicious cycle, and the owner is either oblivious or does not
understand the implications because "well, it works, it generates money" at
the moment right until that plane hits the ground and things blow up.
I've handled a big legacy project, did major updates to it, seen how an
effort of 1 month of my time to drag it into the modern day paid off over
the next 6 months by picking up development speed by 3x with the same team
of 5 people + me. In 1 year we started to literally take away clients from
our competitors who could not keep up with us and we had a literal line of
clients to onboard, we had to scale our sales team 3x and had a backlog of
6 months still. All stemmed from a single decision "I will tackle this, we
need it to update to newer PHP". Business owners were really stoked that
they actually listened to developers.You cannot expect to run code that was written 2 decades ago without major
updates on modern language versions. It's not possible for almost any
language that is being actively developed. Think laterally - instead of
hand-fixing every null check out there, introduce a library that can handle
data structures and handle the nulls for you en mass. Isolate the internals
and just pass already sanitized values into it. Suddenly you cut off like
90% of the needed fixes that prevent you from running your code. It's still
needs fixing, but at least you give it good data to start with, so it does
not error out.Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
Thanks for your reply, I understand everything you mean here by improving a
development flow. I've been responsible to for doing that improvement for
the past 6 years and I'm pretty close to retiring 100% of the legacy code,
but I still need a couple of years to do it. I have long ago convinced the
people in my business that we need to pay this technical debt.
You mentioned that I'm blaming the wrong people, but I'm not blaming anyone
here. I have 4 teams working with me to replace our entire legacy, one bite
at a time, but I lead only 1 of those teams. The other 3 teams have not
only decided that the technical debt needs to be paid, but also its not
worth it to pay it with PHP and have move to Typescript.
My points are:
- development practices has changed and we know it, but it takes time to
shutdown legacy - we are actively working towards paying that technical debt and PHP
improvements are great to help with it, but the deprecations aren't always. - like it or not, there is a community unhappy with how hard it has become
to maintain a PHP codebase.
I believe there's a lot more leeway in breaking BC and fast evolving the
language around projects that have started in 2018+ with automation tests
from day one. Introducing a BC break on PHP 8.3 about something that was
first released on PHP 7.4 is orders of magnitude easier to deal with than
BC breaks on things first Introduced on or before PHP 5.6. If we could just
have a way to opt-in to a faster-paced language for all new code while not
breaking PHP 5.6 features until the previous generation of software can be
retired, that would be awesome.
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:snip to keep the email short
Hello Deleu, I want to highlight your response specifically, because you
blame the wrong people here.
This is the failure of the business owner to plan accordingly and ignore
all the warnings for years and decades. That is if any developer raised any
concerns lately, which I also have seen quite a bit when "yes man" just
shove code into the meatgrinder for a year or two and then just move to the
next job: "It's not my problem, the next guy will deal with this". And that
feeds the vicious cycle, and the owner is either oblivious or does not
understand the implications because "well, it works, it generates money" at
the moment right until that plane hits the ground and things blow up.
I've handled a big legacy project, did major updates to it, seen how an
effort of 1 month of my time to drag it into the modern day paid off over
the next 6 months by picking up development speed by 3x with the same team
of 5 people + me. In 1 year we started to literally take away clients from
our competitors who could not keep up with us and we had a literal line of
clients to onboard, we had to scale our sales team 3x and had a backlog of
6 months still. All stemmed from a single decision "I will tackle this, we
need it to update to newer PHP". Business owners were really stoked that
they actually listened to developers.You cannot expect to run code that was written 2 decades ago without
major updates on modern language versions. It's not possible for almost any
language that is being actively developed. Think laterally - instead of
hand-fixing every null check out there, introduce a library that can handle
data structures and handle the nulls for you en mass. Isolate the internals
and just pass already sanitized values into it. Suddenly you cut off like
90% of the needed fixes that prevent you from running your code. It's still
needs fixing, but at least you give it good data to start with, so it does
not error out.Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihiusThanks for your reply, I understand everything you mean here by improving
a development flow. I've been responsible to for doing that improvement for
the past 6 years and I'm pretty close to retiring 100% of the legacy code,
but I still need a couple of years to do it. I have long ago convinced the
people in my business that we need to pay this technical debt.You mentioned that I'm blaming the wrong people, but I'm not blaming
anyone here. I have 4 teams working with me to replace our entire legacy,
one bite at a time, but I lead only 1 of those teams. The other 3 teams
have not only decided that the technical debt needs to be paid, but also
its not worth it to pay it with PHP and have move to Typescript.My points are:
- development practices has changed and we know it, but it takes time to
shutdown legacy- we are actively working towards paying that technical debt and PHP
improvements are great to help with it, but the deprecations aren't always.- like it or not, there is a community unhappy with how hard it has become
to maintain a PHP codebase.I believe there's a lot more leeway in breaking BC and fast evolving the
language around projects that have started in 2018+ with automation tests
from day one. Introducing a BC break on PHP 8.3 about something that was
first released on PHP 7.4 is orders of magnitude easier to deal with than
BC breaks on things first Introduced on or before PHP 5.6. If we could just
have a way to opt-in to a faster-paced language for all new code while not
breaking PHP 5.6 features until the previous generation of software can be
retired, that would be awesome.
I do have to ask: How any of that is the concern of PHP the language, PHP
the project? This is pure and simple is a company issue. Now they have to
pay for their decision by probably buying some 3rd party extended support.
P.S. I wish all the luck to the teams going with TypeScript rewrite. Having
dealt with NodeJS on a sizeable project - never again (the npm ecosystem
has an atrocious problem with code quality and bugs that are not fixed for
decades - you have to raw dog it on low-level nodejs drivers and modules to
get code that works reliably). I sincerely hope they know what they got
themselves into, considering they were working on a PHP project.
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:snip to keep the email short
Hello Deleu, I want to highlight your response specifically, because you
blame the wrong people here.
This is the failure of the business owner to plan accordingly and ignore
all the warnings for years and decades. That is if any developer raised any
concerns lately, which I also have seen quite a bit when "yes man" just
shove code into the meatgrinder for a year or two and then just move to the
next job: "It's not my problem, the next guy will deal with this". And that
feeds the vicious cycle, and the owner is either oblivious or does not
understand the implications because "well, it works, it generates money" at
the moment right until that plane hits the ground and things blow up.
I've handled a big legacy project, did major updates to it, seen how an
effort of 1 month of my time to drag it into the modern day paid off over
the next 6 months by picking up development speed by 3x with the same team
of 5 people + me. In 1 year we started to literally take away clients from
our competitors who could not keep up with us and we had a literal line of
clients to onboard, we had to scale our sales team 3x and had a backlog of
6 months still. All stemmed from a single decision "I will tackle this, we
need it to update to newer PHP". Business owners were really stoked that
they actually listened to developers.You cannot expect to run code that was written 2 decades ago without
major updates on modern language versions. It's not possible for almost any
language that is being actively developed. Think laterally - instead of
hand-fixing every null check out there, introduce a library that can handle
data structures and handle the nulls for you en mass. Isolate the internals
and just pass already sanitized values into it. Suddenly you cut off like
90% of the needed fixes that prevent you from running your code. It's still
needs fixing, but at least you give it good data to start with, so it does
not error out.Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihiusThanks for your reply, I understand everything you mean here by improving
a development flow. I've been responsible to for doing that improvement for
the past 6 years and I'm pretty close to retiring 100% of the legacy code,
but I still need a couple of years to do it. I have long ago convinced the
people in my business that we need to pay this technical debt.You mentioned that I'm blaming the wrong people, but I'm not blaming
anyone here. I have 4 teams working with me to replace our entire legacy,
one bite at a time, but I lead only 1 of those teams. The other 3 teams
have not only decided that the technical debt needs to be paid, but also
its not worth it to pay it with PHP and have move to Typescript.My points are:
- development practices has changed and we know it, but it takes time to
shutdown legacy- we are actively working towards paying that technical debt and PHP
improvements are great to help with it, but the deprecations aren't always.- like it or not, there is a community unhappy with how hard it has
become to maintain a PHP codebase.I believe there's a lot more leeway in breaking BC and fast evolving the
language around projects that have started in 2018+ with automation tests
from day one. Introducing a BC break on PHP 8.3 about something that was
first released on PHP 7.4 is orders of magnitude easier to deal with than
BC breaks on things first Introduced on or before PHP 5.6. If we could just
have a way to opt-in to a faster-paced language for all new code while not
breaking PHP 5.6 features until the previous generation of software can be
retired, that would be awesome.I do have to ask: How any of that is the concern of PHP the language, PHP
the project? This is pure and simple is a company issue. Now they have to
pay for their decision by probably buying some 3rd party extended support.
I think that's a very honest and on-point question. Which is somewhat
related to what I meant to mention here:
https://externals.io/message/119834#119846 but got called out as "spreading
BS" by Larry here: https://externals.io/message/119834#119868
I don't agree with Larry and I think you're dead right. PHP has a limited
resource and maybe it has decided that the "legacy community" is not a
priority and/or not worth the work. If that's the decision, I have nothing
else to argue and I can accept it.
--
Marco Deleu
On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:snip to keep the email short
Hello Deleu, I want to highlight your response specifically, because
you blame the wrong people here.
This is the failure of the business owner to plan accordingly and
ignore all the warnings for years and decades. That is if any developer
raised any concerns lately, which I also have seen quite a bit when "yes
man" just shove code into the meatgrinder for a year or two and then just
move to the next job: "It's not my problem, the next guy will deal with
this". And that feeds the vicious cycle, and the owner is either oblivious
or does not understand the implications because "well, it works, it
generates money" at the moment right until that plane hits the ground and
things blow up.
I've handled a big legacy project, did major updates to it, seen how an
effort of 1 month of my time to drag it into the modern day paid off over
the next 6 months by picking up development speed by 3x with the same team
of 5 people + me. In 1 year we started to literally take away clients from
our competitors who could not keep up with us and we had a literal line of
clients to onboard, we had to scale our sales team 3x and had a backlog of
6 months still. All stemmed from a single decision "I will tackle this, we
need it to update to newer PHP". Business owners were really stoked that
they actually listened to developers.You cannot expect to run code that was written 2 decades ago without
major updates on modern language versions. It's not possible for almost any
language that is being actively developed. Think laterally - instead of
hand-fixing every null check out there, introduce a library that can handle
data structures and handle the nulls for you en mass. Isolate the internals
and just pass already sanitized values into it. Suddenly you cut off like
90% of the needed fixes that prevent you from running your code. It's still
needs fixing, but at least you give it good data to start with, so it does
not error out.Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihiusThanks for your reply, I understand everything you mean here by
improving a development flow. I've been responsible to for doing that
improvement for the past 6 years and I'm pretty close to retiring 100% of
the legacy code, but I still need a couple of years to do it. I have long
ago convinced the people in my business that we need to pay this technical
debt.You mentioned that I'm blaming the wrong people, but I'm not blaming
anyone here. I have 4 teams working with me to replace our entire legacy,
one bite at a time, but I lead only 1 of those teams. The other 3 teams
have not only decided that the technical debt needs to be paid, but also
its not worth it to pay it with PHP and have move to Typescript.My points are:
- development practices has changed and we know it, but it takes time to
shutdown legacy- we are actively working towards paying that technical debt and PHP
improvements are great to help with it, but the deprecations aren't always.- like it or not, there is a community unhappy with how hard it has
become to maintain a PHP codebase.I believe there's a lot more leeway in breaking BC and fast evolving the
language around projects that have started in 2018+ with automation tests
from day one. Introducing a BC break on PHP 8.3 about something that was
first released on PHP 7.4 is orders of magnitude easier to deal with than
BC breaks on things first Introduced on or before PHP 5.6. If we could just
have a way to opt-in to a faster-paced language for all new code while not
breaking PHP 5.6 features until the previous generation of software can be
retired, that would be awesome.I do have to ask: How any of that is the concern of PHP the language, PHP
the project? This is pure and simple is a company issue. Now they have to
pay for their decision by probably buying some 3rd party extended support.I think that's a very honest and on-point question. Which is somewhat
related to what I meant to mention here:
https://externals.io/message/119834#119846 but got called out as
"spreading BS" by Larry here: https://externals.io/message/119834#119868I don't agree with Larry and I think you're dead right. PHP has a limited
resource and maybe it has decided that the "legacy community" is not a
priority and/or not worth the work. If that's the decision, I have nothing
else to argue and I can accept it.--
Marco Deleu
The reality is, the bandwidth developer-wise is just not there. Not even
close. So PHP does its best effort to keep BC, but up to a point while it
is sustainable. Beyond that point, as in 3 years of support, the older
versions have to be let go and development needs to continue. The project
has the rest of the programming world to keep pace with the limited
resources it has.
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
Hi,
This is a really interesting thread and am glad that Stephan raised it as I've been thinking along similar lines for a while now and am glad I'm not the only one.
Considering the range of people adding comments (especially someone like Mark) then I would hope everyone agrees that this deserves a full discussion (though am now concerned by a couple of Larry's comments that I've referenced below). If I may though, I'd like to take it back to Stephan's original point as I feel there is a bit of digression (though some is really interesting).
I generally come across 3 types of projects:
- Projects that were originally developed a number of years ago and have not been updated since
- Projects that were originally developed a number of years ago and have been updated regularly since
- Projects that were originally developed in the last 5 years and have been updated regularly since
Generally projects in 1 match what Stephan described:
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).
I've tried to keep this generic, but in a lot of cases I see this with local government work that was developed several years ago (generally PHP 5). They had budget up front to build something but then expected to maintain it without any code changes, just by updating the OS and PHP. They perfectly match Stephan's use case group:
I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically.
A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much.
These tend to run for 10 years plus.
Projects in 2 are the trickiest. They're often projects that were started in PHP 5 (or in some cases even 4) and have been upgraded over time. They're generally well maintained and structured code bases although don't have full test coverage. For these the upgrade to PHP 7 took a lot of planning and effort (and some of them have been my projects since the beginning so unlike the others I can't always even blame other people for most of the original decisions as they were mine 15-20 years ago! ), though that was unsurprising given the context, but that process then needed to be repeated for PHP 8 (as previously mentioned, null handling was our biggest issue especially as we couldn't change our integrations with several hundred partners).
Projects in 3 are generally modern PHP applications, often using frameworks. They tend to be the easiest to maintain and upgrade as they're written as modern applications with full test coverage. Once you throw in the business processes around upgrading though they're still not as easy as is being suggested in some places here :)
As Andreas said:
The PHP ecosystem even just in the last 10 years has changed completely, with composer, more mature frameworks, easily usable independent components and even static analyzers. For me that ecosystem is the big value proposition of PHP, in addition to a good standard library.
Does this mean that projects which use the traditional PHP approach (i.e. without the complexity) are now not considered a good fit for PHP?
Back to Stephan's original question. Is PHP still the best use case for type 1? A long running, simple application that doesn't use Composer or a framework that can be extended slightly over time?
If the answer to that is no then so is the answer to 2. In our case the projects in 2 are generally static because they're critical and therefore have budget, though haven't been upgraded to entirely new applications as they're overly complex, integrated with multiple partners or subject to legal regulations. Is PHP still a suitable language for building a long running, complex application that needs to be maintained for 20 years plus? The issue with this is more to do with the frequency of breaking changes?
Following on from that then I had some other thoughts and questions. I'm not suggesting that the issue isn't that there weren't warnings, and that deprecation notices weren't in place. The issue wasn't that we didn't know that the changes were coming, but that we had to make them.
As Ilija said (and his opinion is obviously very relevant):
Sadly, there's a conflict of interest here. There are people who want to keep running their existing websites without having to make any changes, and there are people who are using PHP daily and would like to see the language evolve. We would like to satisfy both of these groups but that is difficult when they are often directly opposed. I do think that if we only manage to satisfy the former, PHP will gradually become less and less significant.
I think the voting mechanism alone will guarantee that the second group will be pre-dominant as the nature of eligible voters means that they will likely fall into that camp.
I think a lot of Mark's points are valid. I don't think anyone is suggesting that the language should freeze, but I think the point that much of the RFCs and upgrade paths assume that your code base is fully covered by tests and is a modern application is key. I also think Rob Landers' point is also really useful, especially the Rector one.
Again, I think everyone appreciates this is an open source project that has both volunteer and paid developers. Having experienced the all consuming nature of open source projects myself, I will always be grateful for the people whose efforts allow us to build upon them.
Having seen the stories a couple of years ago, and the start of the PHP Foundation that's given us an opportunity (as well as other tools like GitHub Sponsors and Patreon) to financially contribute to these projects but even that isn't enough. I resubscribed to the PHP mailing lists after 12 years last May and do think that a lot of the conversation (and RFCs) could benefit from additional inputs from different voices who aren't focused on the development. I'm as guilty as anyone else as I haven't spoken up before now either.
I also don't think this talk of blaming people is helpful. I don't think people are trying to blame people, but do want to consider how the process could be improved in the wild, particularly for non-IT organisations who build occasional or regular applications. I think everyone acknowledges that development environments and practices are changing but not as quickly or easily as sometimes is suggested.
I'd also like to ask for more detail on some of Larry's points:
I know multiple internals devs who are not in this thread, who have been doing the work of keeping PHP going and moving it forward (and I do not count myself among their number), who took one look at this thread and went "nope, not this crap again, not interested."
The OP at the start of this thread sounded earnest, even if this is a well-deceased horse by now. The initial responses to him were reasonable.
Can I ask where I can read up on this? The first part worries me, but if there's somewhere where we could read up on it then that would be really helpful as I still have similar questions to Stephan. If it is a dead topic then it would be good to read up on the conclusions.
Could internals do better on BC, to make upgrades easier? Yes! I have said so many times. I proposed several possible improvements in the blog post above. Mark Baker has focused on better risk analysis elsewhere in this thread, and that's fine. A more formal, standard way to measure the risk of a change would be a good thing. Let's discuss that.
I've enjoyed reading Larry's article, and will read it again and think it through further. It does make me think that just giving money isn't enough though and this needs more people to give their time and thoughts but would need to understand better how to do that.
Apologies for the long response, or for anything that isn't clear. I will give it some more thought but would appreciate the additional information so I can consider that further.
Thanks very much for all of your inputs, and to all the people who contribute to this project. Whatever questions we are raising I don't think that anyone should think we're not grateful to the efforts of everyone, or the sacrifices people make to keep a project like this going.
Best wishes,
Matt
P.S. Sorry if I've committed a mistake in my trimming, but the original response wouldn't accept as it said it was too large.
The reality is, the bandwidth developer-wise is just not there. Not even
close. So PHP does its best effort to keep BC, but up to a point while it
is sustainable. Beyond that point, as in 3 years of support, the older
versions have to be let go and development needs to continue. The project
has the rest of the programming world to keep pace with the limited
resources it has.--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com mailto:arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
I generally come across 3 types of projects:
- Projects that were originally developed a number of years ago and have not been updated since
- Projects that were originally developed a number of years ago and have been updated regularly since
- Projects that were originally developed in the last 5 years and have been updated regularly since
Interesting categorization, especially the 5 years part. Looks like I
misjudged the magnitude of the shift in the PHP community a few years
back (not just from your categorization, but from what others wrote as
well).
I think of languages as tools specialized for a given problem space.
Even general purpose languages have a lot of design decisions that make
them better suited for specific areas than others (e.g. memory
management, threading, scripting, …). And usually there's some spillover
of thought patterns from one language community to another (e.g. someone
programming Java in PHP, JS in Ruby, C++ in C). I thought those
spillovers were merely affecting the language design a bit more than
usual. After all if I want a statically typed language there are already
ample to choose from.
But this was clearly the wrong mindset on my part. I usually combine
various languages in a project, mostly depending on whats already part
of the environment, well maintained and stable. So my focus is on when
to combine what tools and languages. But from your post and others in
the topic most (if not all) seem to work on larger code bases mostly
focused on PHP. And in this situation it makes more sense to bring
static typing into the used language. Thanks for clearing that up.
Generally projects in 1 match what Stephan described:
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).
I've tried to keep this generic, but in a lot of cases I see this with local government work that was developed several years ago (generally PHP 5). They had budget up front to build something but then expected to maintain it without any code changes, just by updating the OS and PHP. They perfectly match Stephan's use case group:
I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically.
A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much.These tend to run for 10 years plus.
I haven't worked on any government projects, but I guess industry and
process automation isn't that different (maybe a bit less bureaucratic).
Machines run for decades and I guess this also sets the time-frame or
mindset for the software used in there (ERP systems, CRUD-like stuff
that models small processes, etc.). Maintenance of course is part of the
picture but on the software side admins are expected to take care of
that. Actually changing code to keep it running as-is isn't expected,
and of course this shapes budgeting. Except for the industry 4.0
subculture, that seems to be a totally different set of people. But I
have no idea if my experience is representative of the industry. Most of
my experience comes from companies in the range of 100-200 employees
(with maybe 5 IT people) or smaller.
I've used PHP in such environments several times, funnily enough because
it was the preferred option for the admin. Maybe the budgeting is my
hint that I shouldn't do that again.
Apart from that I often employ a way of programming that seems to be
quite different from what other posts describe. I usually optimize for
minimal complexity, minimal dependencies and maximal stability. Taking
advantage of the environment to reduce the number of moving parts where
I can. You could say I hunt for synergies between tools to avoid
complexity. This often means taking a bit longer at the beginning or
sometimes using weird tools because they're already an indispensable
part of the environment. A classic is letting an already existing
webserver handle authentication via LDAP or Active Directory. It pays of
in the long run with low maintenance overhead. It's not zero, bugs
happen, stuff changes, but it's maybe a code change every few years
instead of every few months.
For me this is just another way to write software. It works in some
situations, it doesn't work in others. Since my projects are usually to
small to justify a team of programmers I end up using it quite often though.
Also almost all of my projects are one-off "built something that does X
in our environment" things. Not evolving products that get regularly
extended (I have just one of those). Hence its difficult to piggyback
regular cleanup on feature updates.
I maintain my code and take care of notices and deprecation warnings.
But mainly I try to avoid features that might get deprecated. I restrict
myself to a conservative subset of the language. Last time I've had to
put effort into updating some code bases was with PHP 5.3 (it was just
one small language change, though). It was smooth sailing ever since.
Until PHP 8.2 recently, which indicated that some of my core assumptions
about PHP got out of touch with reality.
Thanks to everyone for sharing your thoughts. All of this gave me a way
better handle on how the PHP community ticks right now. I was surprised
by the emotional component of the discussion but I hope I didn't make to
much of a mess for everyone.
Happy programming
Stephan
several PHP versions will be maintained for 10 years by third-party vendors.
PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com
maintains PHP5.6 with multiple customers paying 6000€/year for 5.6
maintenance.
Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu
Pro 16.04.
Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu
Pro 18.04.
Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu
Pro 20.04.
Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu
Pro 22.04.
Red Hat does something similar for their RHEL customers. ~~
hello,
On Sun, Apr 9, 2023, 1:37 AM Stephan Soller stephan.soller@helionweb.de
wrote: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.I keep reading this in multiple languages, pr even more frameworks.
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.best,
PierreI resent the sentiment of "if your code or development process was exactly
like mine you wouldn't be here complaining" and I believe nobody is asking
PHP to freeze. Not everyone has the ability to fix every deprecation within
a couple of hours and not everyone has tests. Yes, we get it, it's common
knowledge nowadays that code without test is unmanageable, but if you
inherited a 15 year old codebase developed by multiple developers in a
start-up mentality producing code faster than they could actually plan for
and with no tests, its going to take some time to clean that up and if I
take longer than you would, does it mean I matter less as a PHP user?PHP 8 is pretty great to work with and a lot better than previous versions,
but there was no opt-in aspect to a lot of PHP breakages. All that we're
asking here is for a bit more forgiveness to existing code that was
developed 2 decades ago by a complete different generation and still need
to run today while we clean it up.
several PHP versions will be maintained for 10 years by third-party vendors.
PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com
maintains PHP5.6 with multiple customers paying 6000€/year for 5.6
maintenance.
Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu
Pro 16.04.
Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu
Pro 18.04.
Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu
Pro 20.04.
Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu
Pro 22.04.
I'm glad that some people can make money out of all this. The 70+ hours
a week that I put in to maintaining my own libraries nets me €16,30 a
month from a userbase that averages 120k downloads a day
--
Mark Baker
I resent the sentiment of "if your code or development process was exactly
like mine you wouldn't be here complaining" and I believe nobody is asking
PHP to freeze. Not everyone has the ability to fix every deprecation within
a couple of hours and not everyone has tests. Yes, we get it, it's common
knowledge nowadays that code without test is unmanageable, but if you
inherited a 15 year old codebase developed by multiple developers in a
start-up mentality
This is wrong in so many levels Agility mindset, startup or not, does not
prevent to do the required cleanups.
These, by the way, are yearly, worst case.
producing code faster than they could actually plan for and with no tests,
its going to take some time to clean that up and if I take longer than you
would, does it mean I matter less as a PHP user?PHP 8 is pretty great to work with and a lot better than previous
versions, but there was no opt-in aspect to a lot of PHP breakages. All
that we're asking here is for a bit more forgiveness to existing code that
was developed 2 decades ago by a complete different generation and still
need to run today while we clean it up.
Many things that will actually break codes (removal of features f.e.), have
been deprecated for years.
as it has been mentioned, many distributions provide longer support for
older php versions.
If you want the latest php version, you will have to prepare for it,
constantly and changing, cleaning your code constantly. This is done as
part of the daily feature additions, no need to ask a PO or whoever else,
just add it to your estimates (if you still use them).
However, asking, as nicely as you did, the volunteers here to do it for you
as the language level, won't work.
best,
Pierre
I understand agency work, managers pushing new features instead of a
cleaning some legacy.however years of ignoring deprecation notices (very few were introduced
right before 8.0).Most of them could have been fixed within a couple of hours in any code
base, if they had tests.
I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.
We're NOT asking PHP to freeze!
We're asking for proper analysis of the effects of these changes on end
users, and proper consideration of the time that it will take for
end-users to upgrade... and the answer to that is NOT "within a couple
of hours". Call it unnecesary overhead if you will, but many tech teams
have process flows for their work that don't simply entail "run rector
on your codebase and deploy". Even just the admin overheads of raising a
ticket for the change, creating a Merge Request, Peer Review, etc can
take a few hours of time in many teams. And that's before making the
assumption that all older code has a good test suite, and CI pipeline...
if it has, then it's probably code that's being updated regularly
anyway, by developers that do try to keep everything up-to-date.
Nor are end-user developers the only people that are affected. End-user
developers typically have the luxury of writing their code for a single
version of PHP, so upgrading the version is a step from one version to
the next. Library writers don't have that luxury: their codebase
normally has to work with a range of PHP versions including the latest
release; and any fixes that are made for the latest release still have
to work with older PHP versions, which can take significantly more
effort to maintain.
--
Mark Baker
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
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.
I think the php focus has shifted from its original ethos. PHP was
designed to be a tool to access sql databases and so the language was
quite simple.
Now php has become so difficult that people are asking what is the point
pf PHP when programming languages such as c# or C or C++ or JS can do
everything. It is difficult to learn these languages but so is PHP
because it is becoming more like a desktop programming language. Might
as well spend time learning main stream programming languages.
PHP should focus on one thing and one thing only and that is to be the
simplest tool for sql servers, mainly MySQL but also try supporting
MS-SQL and PL-SQL (Oracle's premium database system).
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.I think the php focus has shifted from its original ethos. PHP was
designed to be a tool to access sql databases and so the language was
quite simple.Now php has become so difficult that people are asking what is the
point pf PHP when programming languages such as c# or C or C++ or JS
can do everything. It is difficult to learn these languages but so is
PHP because it is becoming more like a desktop programming language.
Might as well spend time learning main stream programming languages.PHP should focus on one thing and one thing only and that is to be the
simplest tool for sql servers, mainly MySQL but also try supporting
MS-SQL and PL-SQL (Oracle's premium database system).
I think this thread's focus has shifted from its original ethos...
i'll see myself out ;)
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.I think the php focus has shifted from its original ethos. PHP was
designed to be a tool to access sql databases and so the language was
quite simple.Now php has become so difficult that people are asking what is the
point pf PHP when programming languages such as c# or C or C++ or JS
can do everything. It is difficult to learn these languages but so is
PHP because it is becoming more like a desktop programming language.
Might as well spend time learning main stream programming languages.PHP should focus on one thing and one thing only and that is to be the
simplest tool for sql servers, mainly MySQL but also try supporting
MS-SQL and PL-SQL (Oracle's premium database system).I think this thread's focus has shifted from its original ethos...
i'll see myself out ;)
Touché.
This was just too classy of them not to acknowledge.