Re: [PHP-DEV] Future stability of PHP?
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
Re: [PHP-DEV] PHP Modules
> On Apr 10, 2023, at 20:40, Michael Morris wrote: > > This will be long. Yes, it's long, so I'm going to focus on a couple things and not quote too much. > I propose PHP Modules to hold new features. What you seem to have described is improved lexical scoping. Rather than a shared "global" scope for classes, functions, constants, and variables, you'd like to allow files, or perhaps even statement lists (open brace to closed brace) to work as either independent or compositional scopes. Basically, make scopes in a certain mode of PHP act more like Javascript. I'll be honest, if we could throw away PHP's old behavior and make this the only mode, I'd be pretty happy. We can't of course, at best we'd have to mix (and yes, I know that's part of your suggestion). This is a LOT of complexity. Not impossible, nothing is, but I'm fairly confident it would make maintaining the runtime harder, and would notably slow execution. Not saying "no", since I lack that power, but I do want to make it clear how HARD this feature would be to implement well. > PHP Modules also would not > parse as templates at all - no opening that will be a headache for IDE makers, but it's not insurmountable). I would suggest, as a compromise, keep the initial open tag (or maybe an alternative one, like I hope this helps, or at least spurs a conversation to come up with > something to address this issue. Lastly, like the stability thread, this isn't a new suggestion, and I'd recommend googling back through the archives for prior discussions. Past failures don't mean it won't work today... Opinions change and so does the runtime, but it may be helpful to understand the complexities presented by this strategy, and what the objections to it will likely boil down to. See also "PHP Editions" which is a different, but closely related proposal put forth by Andi as recently as the 7.x era. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
> 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. I'm sorry. I must be misunderstanding you. Are you implying PHP has no native extension mechanism/API? PHP has had a native extension API since PHP 3. Longer technically, but only the PHP 3 and later APIs are still supported. Yes. I must not have understood you. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP Modules
This will be long. I've read over the Future Stability thread and taken it in, and decided to mull over an idea I touched on over a decade ago that I think might help. Also, in the interceding years the JavaScript community has overcome a compatibility issue using this technique, so we might do the same. The crux of the stability problem is the need to update functions without introducing a BC break. Adding in new features without removing old ones also makes it confusing to incoming programmers as to what to use. I propose PHP Modules to hold new features. The existing namespace and functions would be left alone. Existing files would also not be affected - the behavior of PHP modules would be entirely opt in. They would work similar JavaScript modules - they would use the import keyword and the include, require, include_once and require_once directives would pitch an error if used in a PHP module. PHP Modules also would not parse as templates at all - no opening
Re: [PHP-DEV] Future stability of PHP?
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: 1. Projects that were originally developed a number of years ago and have not been updated since 2. Projects that were originally developed a number of years ago and have been updated regularly since 3. 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
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 01:08, Deleu wrote: > > > On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks > wrote: > >> >> >> On Tue, 11 Apr 2023 at 00:03, Deleu wrote: >> >>> >>> >>> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks >>> 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.godj...@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. >>> >> 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 >
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 01:12, Mark Baker wrote: > On 10/04/2023 23:33, Arvids Godjuks wrote: > > > >> 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
Re: [PHP-DEV] Future stability of PHP?
On 11/04/2023 00:03, Larry Garfield wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 23:33, Arvids Godjuks wrote: 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
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks wrote: > > > On Tue, 11 Apr 2023 at 00:03, Deleu wrote: > >> >> >> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks >> 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.godj...@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. >> >>> > 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
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, at 8:47 PM, Deleu wrote: > On Mon, Apr 10, 2023, 2:26 PM Larry Garfield wrote: > >> >> 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. >> >> https://peakd.com/hive-168588/@crell/upgrading-php-upgrades > > > 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%
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 00:03, Deleu wrote: > > > On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks > 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.godj...@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. > >> 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.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Future stability of PHP?
On Mon, 10 Apr 2023 at 23:43, Mark Baker wrote: > On 10/04/2023 19:04, Arvids Godjuks wrote: > > 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
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks wrote: > > > On Mon, 10 Apr 2023 at 21:30, Deleu wrote: > >> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: >> >> > hello, >> > >> > >> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller < >> stephan.sol...@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 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.godj...@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
[PHP-DEV] Re: Allowing $a = foo($a) to operate in-place (was Re: [PHP-DEV] Array spread append)
Hi
On 10/04/2023 22:11, Tim Düsterhus wrote:
> Hi
>
> On 4/10/23 21:50, Niels Dossche wrote:
>>> The suggested optimization of "the input is overwritten with the output"
>>> would then also allow to avoid introducing reference parameters just for
>>> optimization purposes. The sort() family comes to my mind and also the
>>> shuffle() function. Randomizer::shuffleArray() already returns a copy and
>>> thus would benefit from the proposed optimization for $a =
>>> $r->shuffleArray($a).
>>>
>>
>> I did extend my optimization since the first time I posted it here.
>> It can handle two cases:
>> - $x = array_something($x, ...) like I previously showed with array_merge
>> - $x = array_something(temporary_array_with_refcount_1,...) which is new
>>
>> There is one caveat with the first optimization: it is only safe if we know
>> for sure no exception can happen during array modification.
>> Because, if an exception happens during modification, then the changed array
>> is already visible to the exception handler, but this isn't allowed because
>> the assignment didn't happen yet.
>> This "exception problem" does not happen for the second optimization though.
>
> I see. That makes stuff certainly more complicated, because an exception can
> also arise in an error handler (i.e. for any warnings and notices).
>
Right. Thanks for pointing this out! I completely forgot about this.
That's unfortunate... So far only the array_unique optimization will have
trouble with this. I added a check now that checks if a user handler is
installed.
In any case, if anyone is interested, I created a PR against my fork
(https://github.com/nielsdos/php-src/pull/5) where I'm tinkering with the
optimization idea.
> It's also not just about visibility to the exception handler, but also
> "incomplete modifications" in cases like these:
>
> try {
> $foo = something($foo);
> } catch (\Exception) {}
>
> // $foo might or might not be fully modified.
>
>> So I looked if it was possible to do the optimization for shuffleArray.
>> It is only possible for the second case, because I see some EG(exception)
>> checks inside php_array_data_shuffle().
>> Unless we can determine upfront which random algorithms have an
>> exception-free range function.
>
> For the internal engines this is easy (when ignoring extensions):
>
> - Mt19937
> - PcgOneseq128XslRr64
> - Xoshiro256StarStar
>
> ... are all infallible.
>
> - Secure
>
> ... is fallible (it doesn't fail in practice on modern OSes, though [1])
>
> Any userland engine (engine_user.c) can do anything it wants, of course.
> Unfortunately with Secure being fallible, this optimization is of little use
> in practice. The same would likely be true for a non-reference sorting
> function, because of incomparable values and userland comparison handlers
> that can all kinds of unsafe stuff.
>
That's unfortunate. Then it does indeed seem like the optimization will not
work well for your use case :/
> Best regards
> Tim Düsterhus
>
> [1] For a future major we *might* be able to make a working CSPRNG a hard
> requirement.
Kind regards
Niels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 21:01, Hans Henrik Bergan wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 2:26 PM Larry Garfield wrote: > > 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. > > https://peakd.com/hive-168588/@crell/upgrading-php-upgrades 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?
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 19:04, Arvids Godjuks wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 16:10, Thomas Bley wrote:
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 18:17, Pierre Joye wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Allowing $a = foo($a) to operate in-place (was Re: [PHP-DEV] Array spread append)
Hi
On 4/10/23 21:50, Niels Dossche wrote:
The suggested optimization of "the input is overwritten with the output" would
then also allow to avoid introducing reference parameters just for optimization purposes.
The sort() family comes to my mind and also the shuffle() function.
Randomizer::shuffleArray() already returns a copy and thus would benefit from the proposed
optimization for $a = $r->shuffleArray($a).
I did extend my optimization since the first time I posted it here.
It can handle two cases:
- $x = array_something($x, ...) like I previously showed with array_merge
- $x = array_something(temporary_array_with_refcount_1,...) which is new
There is one caveat with the first optimization: it is only safe if we know for
sure no exception can happen during array modification.
Because, if an exception happens during modification, then the changed array is
already visible to the exception handler, but this isn't allowed because the
assignment didn't happen yet.
This "exception problem" does not happen for the second optimization though.
I see. That makes stuff certainly more complicated, because an exception
can also arise in an error handler (i.e. for any warnings and notices).
It's also not just about visibility to the exception handler, but also
"incomplete modifications" in cases like these:
try {
$foo = something($foo);
} catch (\Exception) {}
// $foo might or might not be fully modified.
So I looked if it was possible to do the optimization for shuffleArray.
It is only possible for the second case, because I see some EG(exception)
checks inside php_array_data_shuffle().
Unless we can determine upfront which random algorithms have an exception-free
range function.
For the internal engines this is easy (when ignoring extensions):
- Mt19937
- PcgOneseq128XslRr64
- Xoshiro256StarStar
... are all infallible.
- Secure
... is fallible (it doesn't fail in practice on modern OSes, though [1])
Any userland engine (engine_user.c) can do anything it wants, of course.
Unfortunately with Secure being fallible, this optimization is of little
use in practice. The same would likely be true for a non-reference
sorting function, because of incomparable values and userland comparison
handlers that can all kinds of unsafe stuff.
Best regards
Tim Düsterhus
[1] For a future major we *might* be able to make a working CSPRNG a
hard requirement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Array spread append
Hey Tim On 10/04/2023 14:45, Tim Düsterhus wrote: > Hi > > On 4/8/23 22:17, Niels Dossche wrote: >> I think this could be made more generic, and be cleaned up. >> But I don't know if something like this is desired in PHP. > > Yes, please. I believe that “performance” should not influence API design if > it can be avoided. Instead the heavy lifting of optimization should be done > by the engine (see also: https://externals.io/message/118896#118921). > I agree. > The suggested optimization of "the input is overwritten with the output" > would then also allow to avoid introducing reference parameters just for > optimization purposes. The sort() family comes to my mind and also the > shuffle() function. Randomizer::shuffleArray() already returns a copy and > thus would benefit from the proposed optimization for $a = > $r->shuffleArray($a). > I did extend my optimization since the first time I posted it here. It can handle two cases: - $x = array_something($x, ...) like I previously showed with array_merge - $x = array_something(temporary_array_with_refcount_1,...) which is new There is one caveat with the first optimization: it is only safe if we know for sure no exception can happen during array modification. Because, if an exception happens during modification, then the changed array is already visible to the exception handler, but this isn't allowed because the assignment didn't happen yet. This "exception problem" does not happen for the second optimization though. So I looked if it was possible to do the optimization for shuffleArray. It is only possible for the second case, because I see some EG(exception) checks inside php_array_data_shuffle(). Unless we can determine upfront which random algorithms have an exception-free range function. > Best regards > Tim Düsterhus Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
Hello George,
I'm not sure I'm 100% correct but I think that this RFC still allows to
call different functions for the same code, just not in the same run.
Consider this pseudocode:
//- funcs.php
namespace My;
function myfunc(...) { ... }
function array_map(...) { ... }
//- code1.php
namespace My;
myfunc(1); // autoload triggered
// bonus points if it's a different file or some obscure method
array_map(strlen(...), []); // My\array_map
//- code2.php
namespace My;
// no prior autoload
array_map(strlen(...), []); // global array_map
And if I understand the current order of execution correctly, here is a
more extreme example:
//- moreextreme.php
namespace My;
if (some_random()) {
array_map('My\myfunc', []); // global array_map
} else {
array_map(myfunc(...), []); // My\array_map
}
--
Anton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
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. ~~ On Mon, 10 Apr 2023 at 20:30, Deleu wrote: > > On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > > > hello, > > > > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > > 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. > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, 10 Apr 2023 at 21:30, Deleu wrote: > On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > > > hello, > > > > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > > > 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 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.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Future stability of PHP?
On Sun, 9 Apr 2023 at 22:52, Deleu wrote: > 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
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > 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. >
Re: [PHP-DEV] Future stability of PHP?
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 Pierre Joye hat am 10.04.2023 18:17 CEST geschrieben: > > > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, at 3:32 AM, Deleu wrote: > On Sat, Apr 8, 2023, 6:04 PM Ilija Tovilo wrote: > >> >> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, 10 Apr 2023 at 19:18, Pierre Joye wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > 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.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Future stability of PHP?
>
> 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();
```
On Mon, Apr 10, 2023 at 8:35 AM Jeffrey Dafoe wrote:
>
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Future stability of PHP?
hello, On Sun, Apr 9, 2023, 1:37 AM Stephan Soller 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
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 3:59 PM Craig Francis 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?
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Mon, Apr 10, 2023 at 10:01 AM Ondřej Mirtes wrote: > I don’t like the proposed function names: > > autoload_register_class to me reads like “register this class for > autoloading”. If I observe the intended meaning correctly, it should be > called “register_class_autoloader”. > > Same for autoload_register_function - better name would be > “register_function_autoloader”. > > Other functions should be renamed accordingly. Function names should read > like a sentence, like a command. > > On Mon 10. 4. 2023 at 14:17, G. P. B. wrote: > > > Hello Internals, > > > > Dan and I would like to propose a new core autoloading mechanism that > fixes > > some minor design issues with the current class autoloading mechanism and > > introduce a brand-new function autoloading mechanism: > > https://wiki.php.net/rfc/core-autoloading > > > > The existing SPL autoloading functions would become aliases to the new > Core > > ones and will continue to work without any migrations needing to be > > performed. > > > > Hope to hear your opinions about this! > > > > Best regards, > > > > George P. Banyard > > > -- > > Ondřej Mirtes > I'm guessing autoload_* was chosen because PHP internal functions are bundled by prefix and register_* would not make a good bundle name for the autoloading functionality. What helps me when thinking about PHP internals function is to assume the first word is a class, such as: $autoload = new Autoload(); And then everything after the first underscore is a method name, such as $autoload->register_class();. What I can recommend in this case is to make them autoload_register_class_loader() and autload_unregister_class_loader(), but prefixing everything with register_* would be essentially $register = new Register();, but register what? -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 10:48, Andreas Leathley wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
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 hat am 10.04.2023 16:48 CEST geschrieben: > > > Hi > > On 4/10/23 16:37, Thomas Bley wrote: > > Regarding compatibility promise, I'd also like to mention that things are > > quite complex now, e.g. > > > > https://3v4l.org/VfAr4 > > > > has 4 different outputs between php 7.x and 8.x. From userland perspective, > > having > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Hi On 4/10/23 16:37, Thomas Bley wrote: Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g. https://3v4l.org/VfAr4 has 4 different outputs between php 7.x and 8.x. From userland perspective, having 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Regarding compatibility promise, I'd also like to mention that things are quite
complex now, e.g.
https://3v4l.org/VfAr4
has 4 different outputs between php 7.x and 8.x. From userland perspective,
having Craig Francis hat am 10.04.2023 14:58 CEST
> geschrieben:
>
>
> On 9 Apr 2023, at 23:10, Kamil Tekiela wrote:
> > 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):
>
> https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php
>
> 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):
>
> https://wiki.php.net/rfc/null_coercion_consistency
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 10.04.2023 14:17, G. P. B. wrote: Hello Internals, Dan and I would like to propose a new core autoloading mechanism I think it would make a lot of sense to have one function for all kind of features, but the user should define which ones. For example: Loader::register(callable $callback, int $type, bool $prepend = false): void; then Loader::register($callback, Loader::TYPE_CLASS | Loader::TYPE_FUNCTION); Or sth like that. My 2c. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
I don’t like the proposed function names: autoload_register_class to me reads like “register this class for autoloading”. If I observe the intended meaning correctly, it should be called “register_class_autoloader”. Same for autoload_register_function - better name would be “register_function_autoloader”. Other functions should be renamed accordingly. Function names should read like a sentence, like a command. On Mon 10. 4. 2023 at 14:17, G. P. B. wrote: > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading > > The existing SPL autoloading functions would become aliases to the new Core > ones and will continue to work without any migrations needing to be > performed. > > Hope to hear your opinions about this! > > Best regards, > > George P. Banyard > -- Ondřej Mirtes
Re: [PHP-DEV] Future stability of PHP?
On 9 Apr 2023, at 23:10, Kamil Tekiela wrote:
> 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):
https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php
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):
https://wiki.php.net/rfc/null_coercion_consistency
Re: [PHP-DEV] Array spread append
Hi On 4/8/23 22:17, Niels Dossche wrote: I think this could be made more generic, and be cleaned up. But I don't know if something like this is desired in PHP. Yes, please. I believe that “performance” should not influence API design if it can be avoided. Instead the heavy lifting of optimization should be done by the engine (see also: https://externals.io/message/118896#118921). The suggested optimization of "the input is overwritten with the output" would then also allow to avoid introducing reference parameters just for optimization purposes. The sort() family comes to my mind and also the shuffle() function. Randomizer::shuffleArray() already returns a copy and thus would benefit from the proposed optimization for $a = $r->shuffleArray($a). Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Make unserialize() emit a warning for trailing bytes
Hi On 3/27/23 19:03, Tim Düsterhus wrote: RFC: Make unserialize() emit a warning for trailing bytes https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Proof of concept implementation is in: https://github.com/php/php-src/pull/9630 The minimum 2 weeks of discussion will be over in a few hours: I believe RFC is fairly simple and the proposal is well-explained. The comments during discussion were generally positive and no new emails came in since day 2 of discussion. With regard to the request of making this an exception, this will not be part of this RFC, as I explained in my previous email. I've also added that to "rejected features" within the wiki. With that said, I plan to open voting later this week (likely Wednesday, time permitting), unless any significant commentary happens in response to this pre-vote announcement. I don't plan any further changes to either the RFC text or the voting widget title. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
Hello Internals, Dan and I would like to propose a new core autoloading mechanism that fixes some minor design issues with the current class autoloading mechanism and introduce a brand-new function autoloading mechanism: https://wiki.php.net/rfc/core-autoloading The existing SPL autoloading functions would become aliases to the new Core ones and will continue to work without any migrations needing to be performed. Hope to hear your opinions about this! Best regards, George P. Banyard
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 1:45 AM Deleu wrote: > > 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 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.
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 04:17 Deleu wrote: > > 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. >
Re: [PHP-DEV] Future stability of PHP?
On 10.04.23 01:44, Deleu wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
