On Mon, Apr 10, 2023, at 10:09 PM, Deleu wrote:
> 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
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
On Tue, Apr 11, 2023, 1:30 AM Deleu wrote:
>
>
> 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
On Tue, 11 Apr 2023 at 12:24, Sara Golemon wrote:
> > I'm saying that the DX for writing extensions is better in other
> languages.
>
> Citation needed. Java's extension API is certainly a hot mess. Python's
> is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice
> at
Hi
On 4/11/23 18:32, Jeffrey Dafoe wrote:
I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths.
You should be able to enable deprecations in production and then check
the type of error within your error handler. If
On Tue, Apr 11, 2023, 22:14 Gunnard engebreth wrote:
>
> On 4/11/23 3:09 PM, Good Guy wrote:
> > On 08/04/2023 19:36, Stephan Soller wrote:
> >>
> >>
> >> 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
On 4/11/23 3:09 PM, Good Guy wrote:
On 08/04/2023 19:36, Stephan Soller wrote:
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
On 08/04/2023 19:36, Stephan Soller wrote:
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)
On Tue, Apr 11, 2023, at 4:32 PM, Jeffrey Dafoe wrote:
> Can you expand a bit more on your use-case?
>
> We have a lot of classes, a small portion of which use dynamic
> properties, but we do not necessarily know which ones do. It’s
> different than, for example, a change to the count
Essentially the same thing here. Removal of dynamic properties will be the next
big one for my team. It's the deprecations that hit huge swaths of code without
really offering much benefit that are annoying.
Yes, we have a _lot_ of classes. Also multiple versions of Zend framework that
we
> Can you expand a bit more on your use-case?
Here are some things I've deliberately used dynamic properties for:
- development proxies (production uses compiled proxies) for remote
objects [can use attribute or magic functions]
- visitor pattern when hacking on parser packages [in PHP 9,
On Tue, Apr 11, 2023 at 9:29 AM Jeffrey Dafoe wrote:
> Essentially the same thing here. Removal of dynamic properties will be the
> next big one for my team. It's the deprecations that hit huge swaths of
> code without really offering much benefit that are annoying.
>
> Yes, we have a _lot_ of
Original message From: Andreas Leathley
Date: 2023-04-11 07:19 (GMT-08:00) To: internals@lists.php.net Subject: Re:
[PHP-DEV] Future stability of PHP? On 11.04.23 15:56, Jeffrey Dafoe wrote:>> So
turn off the deprecation warnings for now. They're just a he
On Tue, Apr 11, 2023 at 9:18 AM Robert Landers
wrote:
> > You can add `#[AllowDynamicProperties]` to classes where you want to
> allow
> > dynamic properties.
>
> I don't think that will work in PHP 9?
>
>
In Niki's earliest draft, he wanted to completely remove dynamic properties
from *default*
Essentially the same thing here. Removal of dynamic properties will be the next
big one for my team. It's the deprecations that hit huge swaths of code without
really offering much benefit that are annoying.
-Jeff
You can add `#[AllowDynamicProperties]` to classes where you want to allow
> Please double-check the source before sending questions like that to the
> list, since that information is easilly accessible
Sorry, I'll refrain from asking stupid questions in the future.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, Apr 11, 2023, 17:18 Robert Landers wrote:
> > You can add `#[AllowDynamicProperties]` to classes where you want to
> allow
> > dynamic properties.
>
> I don't think that will work in PHP 9?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi
On 4/11/23 16:18, Robert Landers wrote:
You can add `#[AllowDynamicProperties]` to classes where you want to allow
dynamic properties.
I don't think that will work in PHP 9?
As per the corresponding RFC at
https://wiki.php.net/rfc/deprecate_dynamic_properties#proposal:
Classes
On 11.04.23 15:56, Jeffrey Dafoe wrote:
So turn off the deprecation warnings for now. They're just a heads up that
behaviour is going to change in the future, with PHP 9.
I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA
> You can add `#[AllowDynamicProperties]` to classes where you want to allow
> dynamic properties.
I don't think that will work in PHP 9?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Apr 11, 2023 at 3:33 PM Jeffrey Dafoe wrote:
> > was something introduced in a time that the code being written using it
> has
> > 100% test coverage and static analysers protecting it. It's easier for
> me to deal
> > with any BC breaks of PHP 7.1 or higher than it is to deal with
>
> So turn off the deprecation warnings for now. They're just a heads up that
> behaviour is going to change in the future, with PHP 9.
>
> I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA environments but off in
production.
On 11 April 2023 14:33:27 BST, Jeffrey Dafoe wrote:
>> was something introduced in a time that the code being written using it has
>> 100% test coverage and static analysers protecting it. It's easier for me to
>> deal
>> with any BC breaks of PHP 7.1 or higher than it is to deal with
> was something introduced in a time that the code being written using it has
> 100% test coverage and static analysers protecting it. It's easier for me to
> deal
> with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations
> of
> PHP 5.6 or lower.
Essentially the same thing
On Tue, Apr 11, 2023 at 5:40 AM Alex Wells wrote:
> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
>
>> I don't want to use those weird stuff, but I'm
>> doing the best I can to replace every single line of old code that has
>> been
>> written in an era that "best practices for PHP development"
> I'm saying that the DX for writing extensions is better in other languages.
Citation needed. Java's extension API is certainly a hot mess. Python's is
fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice at
first blush, but given that it's closer to an FFI than a
On Tue, 11 Apr 2023 at 03:00, Sara Golemon wrote:
> I'm sorry. I must be misunderstanding you. Are you implying PHP has no
> native extension mechanism/API?
>
No. I can't see that reading in what I wrote.
I'm saying that the DX for writing extensions is better in other languages.
And that
Just to follow up on that, and going totally off topic, I was reading about
thanks.dev the other day.
One of our concerns is that we can easily give money to top level projects or
things we consciously add but how do you give it to all the dependencies and
the thanks.dev approach seems a good
What's meaningful in this sense?
I have a budget for supporting open source projects (back to my money v time
point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS
fees we pay elsewhere (even sometimes as a safety net) to the Foundation but
believe that the money we
I'm also curious to hear whether any participants in this thread do/did
support the PHP foundation in any tangible way :D
If you treat it like an LTS provider, perhaps it's time to pay up the LTS
support fees?
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On
On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
> I don't want to use those weird stuff, but I'm
> doing the best I can to replace every single line of old code that has been
> written in an era that "best practices for PHP development" were not what
> you and I know today.
>
I still do not
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
> 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
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
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*
>
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
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
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
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,
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
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
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
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,
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
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,
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
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.
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
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
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
> > >
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
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
> >
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
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
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
> >
>
> 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
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
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
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
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
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
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
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
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
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
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
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
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
On Sun, Apr 9, 2023, 7:10 PM Kamil Tekiela wrote:
>
> I'd rather say that the roadblocks people are facing in upgrading legacy
> projects are not specific to PHP 8, but rather a technical debt acquired
> over the past 10-15 years. Even if nothing would change in PHP 8, people
> would still
On Sun, Apr 9, 2023 at 7:10 PM Kamil Tekiela wrote:
> > But the cost is catastrophic. If you have a legacy codebase hanging over
> your head you probably know how hard it is to upgrade it.
>
> I wonder about this every time I hear this claim. What exactly changed in
> PHP 8.0 that made the
> But what's the point of starting a greenfield project in PHP while
Typescript is right there?
If that is true then we have pushed PHP to its death. PHP is dead and we
can move on to other projects. But that's obviously not true. I could claim
the complete opposite: why start a project in
On Sat, Apr 8, 2023, 5:47 PM Dan Liebner wrote:
> I agree with the OP's sentiment here. If I was starting a codebase from
> scratch today, I'd probably go with Node. I find that writing modern
> JavaScript is way easier than writing PHP these days, and the breaking
> changes in newer PHP
It depends on your environment and usecase.
For me Node is actually a curious case. Node itself and its APIs are
very stable and the stability of each API is clearly marked in the docs.
But the NPM based ecosystem is almost the exact opposite. Using it for
anything else than quick
On 08.04.23 23:04, Ilija Tovilo wrote:
> Hi Stephan
>
>> I'm sorry if this isn't the correct mailing list for that discussion
but I
>> couldn't find a more appropriate one where people actually know how the
>> wind is
>> blowing.
>
> No worries, this seems like the appropriate place.
>
>> Is
Hi Stephan
> I'm sorry if this isn't the correct mailing list for that discussion but I
> couldn't find a more appropriate one where people actually know how the
> wind is
> blowing.
No worries, this seems like the appropriate place.
> Is there a way to tell which APIs and language features
I agree with the OP's sentiment here. If I was starting a codebase from
scratch today, I'd probably go with Node. I find that writing modern
JavaScript is way easier than writing PHP these days, and the breaking
changes in newer PHP versions make writing code harder rather than easier.
PHP is the
Hi Stephan,
Generally, PHP tries to keep as much backwards compatibility as possible.
Breaking changes are limited to minimum and done in the least obstructive
way possible. When a deprecation is introduced, you have at least 3 years
to update your code.
But PHP also tries to move forward and the
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
78 matches
Mail list logo
