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
> 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
> 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
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
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,
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
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
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.
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
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
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 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
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 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
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
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
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
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
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
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
48 matches
Mail list logo
