Here are my comments about the last PR
https://github.com/php/php-src/pull/10345
Max asked to repost them in this thread:
In my opinion this should not be accepted.
Despite the intention is good, this huge patch doesn't improve anything but
adds new questions.
- It introduces new include
On 2023/01/16 13:48, "G. P. B." wrote:
> Moreover, having those sorts of changes be RFCs seems counterproductive as
> the only people who care about this are actual core and extensions
> developers and this opens the gate for petty RFCs to resolve coding style
> disagreements.
How shall we
On Wed, 18 Jan 2023 at 09:01, Max Kellermann wrote:
> On 2023/01/16 13:48, "G. P. B." wrote:
> > Moreover, having those sorts of changes be RFCs seems counterproductive
> as
> > the only people who care about this are actual core and extensions
> > developers and this opens the gate for petty
On 2023/01/18 12:51, "G. P. B." wrote:
> So I think creating an official RFC is the only way.
Okay then, I'm now at step 2 of https://wiki.php.net/rfc/howto
I registered the account "maxk" on the Wiki - please grant me RFC
karma!
Max
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi all!
While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP
8.1 builds are still using OpenSSL 1.1.1. However, OpenSSL 1.1.1 is
only supported till 2023-09-11[1], while PHP 8.1 is supported till
2024-11-25[2]. Although I don't like bumping the OpenSSL version in the
middle of
On Tue, 17 Jan 2023 at 18:28, Mark Baker wrote:
> On 17/01/2023 17:28, Craig Francis wrote:
> > I've seen this used a few times, e.g. starting with a numerical value
> (Passport number, NHS number, Social Security Number, Date of Birth
> 20230117), and the developer simply appends an
On 18.01.2023 at 12:58, Max Kellermann wrote:
> On 2023/01/18 12:51, "G. P. B." wrote:
>> So I think creating an official RFC is the only way.
>
> Okay then, I'm now at step 2 of https://wiki.php.net/rfc/howto
>
> I registered the account "maxk" on the Wiki - please grant me RFC
> karma!
Done.
> Le 17 janv. 2023 à 15:28, G. P. B. a écrit :
>
> Hello Internals,
>
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
Hi,
Adding a `str_increment(...)` function that roughly replicates the
+1, we don't want to bundle and maintain and monkey-patch 1.1.1
ourselves for 14.4 months,
which I guess would be the alternative.
On Wed, 18 Jan 2023 at 13:20, Christoph M. Becker wrote:
>
> Hi all!
>
> While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP
> 8.1 builds are
On 2023/01/18 13:11, "Christoph M. Becker" wrote:
> > I registered the account "maxk" on the Wiki - please grant me RFC
> > karma!
>
> Done. Best of luck!
Thanks.
Here's my RFC: https://wiki.php.net/rfc/include_cleanup
I hope that's correct this way - then we're now at step 5 "Listen to
the
On Tue, 17 Jan 2023, G. P. B. wrote:
> I would like to start the discussion about the Saner
> array_(sum|product)() RFC:
> https://wiki.php.net/rfc/saner-array-sum-product
>
> Currently, the array_sum() and array_product() behave differently than
> their userland implementation as they ignore
On 18 January 2023 15:32:28 GMT, Derick Rethans wrote:
>> The goal of this RFC is to reduce language complexity by making $v++
>> behave like $v += 1 and $v-- behave like $v -= 1;
>
>If that is the goal, then I would agree with this RFC.
>
>However, changing the PERL string increment feature
Hello all,
I'm following up to give you a quick update on the PHP port to the wasm32-wasi
platform.
We have released the port of 8.1.11 [1] and 8.2.0 [2] PHP versions.
We also had a really nice contribution from Simon Menke that we will be merging
soon that enables setjmp/longjmp emulation,
Den 2023-01-18 kl. 13:22, skrev G. P. B.:
On Tue, 17 Jan 2023 at 18:28, Mark Baker wrote:
On 17/01/2023 17:28, Craig Francis wrote:
I've seen this used a few times, e.g. starting with a numerical value
(Passport number, NHS number, Social Security Number, Date of Birth
20230117), and the
Hi
On 1/18/23 15:55, Max Kellermann wrote:
Here's my RFC: https://wiki.php.net/rfc/include_cleanup
I hope that's correct this way - then we're now at step 5 "Listen to
the feedback, and try to answer/resolve all questions" - so please
give feedback :-)
Don't forget to add it to the
On Tue, 17 Jan 2023, G. P. B. wrote:
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by making $v++
> behave like $v += 1 and $v--
> Le 18 janv. 2023 à 16:20, Derick Rethans a écrit :
>
> if (version_compare(phpversion(), "8.4.0", ">")) {
> setcookie("test", "value", samesite: SameSite::Stricter);
> } else {
> setcookie("test", "value", samesite: SameSite::Strict);
> }
Or even, replace `version_compare(...)`
It seems to me that if you truly want to clean up this specific part
of the language, you are going to have to play the long game:
1. New functions are added for the perl behavior of string increment
and decrement. No warnings are given in code, but call-outs are made
in upgrading and other
Am 18.01.2023 um 16:26 schrieb Claude Pache :
>> Le 18 janv. 2023 à 16:20, Derick Rethans a écrit :
>>
>> if (version_compare(phpversion(), "8.4.0", ">")) {
>> setcookie("test", "value", samesite: SameSite::Stricter);
>> } else {
>> setcookie("test", "value", samesite: SameSite::Strict);
>> }
>
On Mon, 16 Jan 2023, Max Kellermann wrote:
> On 2023/01/16 13:38, Kamil Tekiela wrote:
>
> > What's the impact on other maintainers, especially extension
> > maintainers?
>
> Other maintainers may need to determine which includes they really
> need, instead of relying on everything always
On 2023/01/18 16:41, Derick Rethans wrote:
> Including a "random" zend header also sounds like a great benefit. I
> shouldn't need to care as an extension author which header enables which
> internal function(s) for usage.
So, in your opinion, choosing an arbitrary of the 95 Zend/zend*.h
On Tue, 17 Jan 2023, Christian Schneider wrote:
> Am 17.01.2023 um 15:59 schrieb G. P. B. :
> >
> > I might be again misunderstanding, but one cannot extend an enum as
> > they are final classes under the hood. Currently, the only other
> > native enum is the one that was added with the
On 18 Jan 2023, at 12:22, G. P. B. wrote:
> [...]
> I appreciate being shown concrete cases about the useful ness of this
> operation.
> The reason I didn't go with adding support for decrementing alphanumeric
> strings is that it was unanimously rejected.
> However, if Rowan's suggestion of
Hi Rafael,
you have my support to add WASM/WASI arch support natively.
Our usecase is to evaluate some php code in client/browser directly and
thus improve client response times.
Based on the php-src contributing policy, minor version branches
(PHP-8.2, ...) are bugfix branches only, thus
On Wed, Jan 18, 2023, 19:57 Claude Pache wrote:
>
>
> > Le 18 janv. 2023 à 18:27, Kamil Tekiela a écrit :
> >
> > Strings should not be incrementable unless they are numeric strings. The
> > current "feature" is more like a bug from xkcd comic.
> https://xkcd.com/1172/
> >
> > But as there is a
On Wed, 18 Jan 2023 at 15:06, Derick Rethans wrote:
> On Tue, 17 Jan 2023, G. P. B. wrote:
>
> > I would like to start the discussion about the Saner
> > array_(sum|product)() RFC:
> > https://wiki.php.net/rfc/saner-array-sum-product
> >
> > Currently, the array_sum() and array_product() behave
Regards,
On 18 January 2023 16:07:52 GMT, Max Kellermann wrote:
>This argument puzzles me most. I've never heard anybody criticize
>some piece of code for having too MANY code comments, too MUCH
>explanation.
Then I guess you've never heard people quoting Robert "Uncle Bob" Martin, who
is well
Hi
On 1/18/23 18:51, Kamil Tekiela wrote:
As you said yourself, this refactoring has no practical effect on
It has no practical effect *yet*. The headers need to be untangled first
before actual optimization can happen.
Or maybe have all
ZEND headers included with a single header?
That
On 18/01/2023 17:10, Craig Francis wrote:
I agree that some of the incrementing behaviour can be a bit weird, and I would
be happy to see those be deprecated/removed; but I worry that the A, B, ..., Z,
AA, AB, etc is something that works well today, and is likely to be tricky to
find/replace
I like this proposal and I support making the language consistent. I wasn't
aware there were so many inconsistencies with increment/decrement
operators.
When I read the RFC I was a little sceptical about the deprecation of
string increment functionality. It's something I used in the past and I
I am in both camps. I think some slight cleanup might be in order, but not
how you are proposing it. First of all:
- I am against forward struct declarations. I think they decrease code
readability and should be avoided.
- I am against putting comments on #includes. Comments are noise in code
and
> Le 18 janv. 2023 à 18:27, Kamil Tekiela a écrit :
>
> Strings should not be incrementable unless they are numeric strings. The
> current "feature" is more like a bug from xkcd comic. https://xkcd.com/1172/
>
> But as there is a real need for a similar functionality, for example when
>
On 18/01/2023 18:27, Kamil Tekiela wrote:
When I read the RFC I was a little sceptical about the deprecation of
string increment functionality. It's something I used in the past and I see
no easy upgrade path. However, after reading this thread and thinking it
over, I realize that deprecation is
On Wed, Jan 18, 2023 at 10:09 PM Claude Pache
wrote:
>
>
> Le 18 janv. 2023 à 19:33, Alex Wells a écrit :
>
> Classes and methods is the expected way of implementing standard library
> in an OO language. New APIs (such as the new Random api) use OO instead of
> functions and it makes more sense
On Wed, Jan 18, 2023 at 4:17 PM Tim Düsterhus wrote:
> Hi
>
> On 1/18/23 18:51, Kamil Tekiela wrote:
> > As you said yourself, this refactoring has no practical effect on
>
> It has no practical effect *yet*. The headers need to be untangled first
> before actual optimization can happen.
> > Or
On Tue, Jan 17, 2023, at 1:25 PM, Jesse G. Donat wrote:
> I'm looking to measure reaction to a proposal.
>
> My proposal is to have the STDOUT and STDERR global constants always
> defined rather than just when running via CLI.
>
> The variability of their existence is a common cause of confusion
> Le 18 janv. 2023 à 19:33, Alex Wells a écrit :
>
> Classes and methods is the expected way of implementing standard library in
> an OO language. New APIs (such as the new Random api) use OO instead of
> functions and it makes more sense to use OO in this case too: there's likely
> a place
On Wed, 18 Jan 2023 at 14:35, Björn Larsson
wrote:
> Since the alpanumeric_decrement RFC was rejected january 2014 9 years ago,
> could it be an option to bring it up again in conjunctione with your RFC?
>
> Maybe the added value of your RFC could swing the opinion. I mean there has
> been RFC's
Hi
On 1/18/23 21:37, Flávio Heleno wrote:
This may be a silly question, but in that case, wouldn't #ifdef guards keep
the compiler from including/parsing a.h twice?
It's complicated. Modern compilers may include an optimization for
include guards
On Wed, Jan 18, 2023, at 2:25 PM, G. P. B. wrote:
> On Wed, 18 Jan 2023 at 16:03, Levi Morrison
> wrote:
>
>> It seems to me that if you truly want to clean up this specific part
>> of the language, you are going to have to play the long game:
>> 1. New functions are added for the perl behavior
On 18/01/2023 21:25, G. P. B. wrote:
I would like to start the discussion on the Path to Saner
Increment/Decrement operators RFC:
https://wiki.php.net/rfc/saner-inc-dec-operators
The goal of this RFC is to reduce language complexity by making $v++
behave like $v += 1 and $v-- behave like $v -=
41 matches
Mail list logo
