Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute

On Wed, 3 Jan 2024 at 13:17, Max Semenik wrote: > > this actively prevents writing a child class that'd make a parent > serializable if it wants to. > > Wouldn't this violate LSP? > No it doesn't. Making a child class unserializable if the parent is serializable however is violating LSP, and

Re: [PHP-DEV] Pre-RFC: Fixing spec bugs in the DOM extension

On Tue, 26 Dec 2023 at 21:45, Niels Dossche wrote: > Hi internals > > The DOM extension in PHP is used to parse, query and manipulate XML/HTML > documents. The DOM extension is based on the DOM specification. > Originally this was the DOM Core Level 3 specification, but nowadays, that >

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Wed, 13 Dec 2023 at 09:29, Alexander Pravdin wrote: > On Wed, Dec 13, 2023 at 6:11 PM Robert Landers > wrote: > > I just ran `apt install php8.3-decimal` and tried this: > > > > $a = new Decimal\Decimal("1", 2); > > $b = $a + $a; > > PHP Warning: Uncaught TypeError: Unsupported operand

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, 12 Dec 2023 at 21:00, Robert Landers wrote: > On Tue, Dec 12, 2023 at 2:04 PM G. P. B. wrote: > > GMP supports operator overloading > > GMP kinda-sorta-most-of-the-time supports operator overloading. > Sometimes ... it doesn't. I implemented a field library in PHP (f

Re: [PHP-DEV] Re: Proposal: Arbitrary precision native scalar type

Gina P. Banyard On Tue, 12 Dec 2023 at 08:51, Alexander Pravdin wrote: > I just found out that under PHP 8.3, basic arithmetic operations on the > Decimal object variables are no longer supported and cause TypeError. So > this is one more point to implementing native decimals in PHP. > This is

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Fri, 8 Dec 2023 at 10:14, Alexander Pravdin wrote: > On Thu, Dec 7, 2023 at 11:36 PM G. P. B. wrote: > > - Objects are always casted to true, GMP(0) will equal to true. >>> >> >> This is incorrect, GMP object do _not_ support casts to bool >> See https:/

Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute

The implementation is simple and straight to the point, and uses machinery that has been added to the engine to deal more consistently with internal classes. In an ideal world (IMHO) serialization would be opt-in and __serialize() would be used to enable and describe the serialization format.

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Thu, 7 Dec 2023 at 06:36, Alex Pravdin wrote: > Hello internals, > [...] > GMP: > - Workaround: implements the GMP class that allows basic math operations. > - Requires using separate functions for the rest of operations. > > - Objects are always casted to true, GMP(0) will equal to true. >

Re: [PHP-DEV] Inconsistency mbstring functions

On Fri, 1 Dec 2023 at 09:31, Stefan Schiller via internals < internals@lists.php.net> wrote: > Hi, > > I would like to raise attention to an inconsistency in how mbstring > functions handle invalid multibyte sequences. When, for example, > mb_strpos encounters a UTF-8 leading byte, it tries to

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

On Fri, 1 Dec 2023 at 09:35, Jakub Zelenka wrote: > On Fri, Dec 1, 2023 at 9:28 AM G. P. B. wrote: > >> On Thu, 30 Nov 2023 at 23:45, Jakub Zelenka wrote: >> >>> Hi, >>> >>> On Thu, Nov 30, 2023 at 10:13 PM Jorg Sowa wrote: >>> >>&g

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

On Thu, 30 Nov 2023 at 23:45, Jakub Zelenka wrote: > Hi, > > On Thu, Nov 30, 2023 at 10:13 PM Jorg Sowa wrote: > >> >> Creating aliases for Intl extension constants has been accepted with 10 >> votes yes and 6 votes no. >> >> > This means that it is declined as you need 2/3 of votes to pass...

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

On Wed, 22 Nov 2023 at 07:36, Mike Schinkel wrote: > On Nov 21, 2023 at 11:33 PM, > wrote: > > What is the point of a major release if we cannot even do such a BC break? > We don't even know when PHP 9.0 is going to happen yet. > > > I have been using Go for about four years now and it seems

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

On Thu, 16 Nov 2023 at 16:13, Jakub Zelenka wrote: > On Sun, Nov 12, 2023 at 4:48 PM Máté Kocsis > wrote: > > > Hi Internals, > > > > Following my straw poll about the Process resource name, I would like to > > present an RFC which clarifies the rough timeline and the BC promises of > > the

Re: [PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

On Tue, 21 Nov 2023 at 21:10, Ben Ramsey wrote: > We’ve discussed this among release managers, and I’m updating this > thread to clarify that I was mistaken about what the dates for supported > versions mean. These are the dates up until we will accept patches to a > version branch. So, for

[PHP-DEV] Request PHP 8.3 GA release push back

Hello internals, As far as I am aware, the 8.3.0 release is meant to be tagged tomorrow. However, there are at least three known bugs in RC6: - An ext/posix bug [1], which has a fix [2] - Two ext/pgsql bugs around the new pipeline support: - A constant not being exposed [3] - The overall

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

On Wed, 15 Nov 2023 at 23:43, Levi Morrison wrote: > On Wed, Nov 15, 2023 at 2:26 PM Jorg Sowa wrote: > > > > Hello internals! > > I have just opened voting on the RFC to add 4 new rounding modes to > round() > > function. > > > > Voting will end November 30th, 00:00 GMT. > > > > Link: > >

Re: [PHP-DEV] Set register_argc_argv to Off by default

On Wed, 8 Nov 2023 at 16:59, Thomas Chauchefoin < thomas.chauchef...@sonarsource.com> wrote: > Thank you for your early feedback on this suggestion. Without rushing > things, I assume that the next step for me would be to draft an RFC to > formalize this change? > The change seems to be

Re: [PHP-DEV] Set register_argc_argv to Off by default

On Tue, 7 Nov 2023 at 10:33, Thomas Chauchefoin via internals < internals@lists.php.net> wrote: > Hey, > > I recently opened an issue on GitHub [1] to discuss setting > register_argc_argv to Off by default for all SAPIs but cli, embed, and > phpdbg. Ilija Tovilo suggested including this change in

Re: [PHP-DEV] New RFC : empty() function

On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa wrote: > Hi Marcos, > > thanks for feedback. > Could you be clearer about your advice and gimme an example please? > I have edited the RFC content to add highlighting, hopefully you can now use that to improve the RFC text. However, I'm not very

Re: [PHP-DEV] Re: Basic Type Alias

On Sun, 29 Oct 2023 at 20:36, Robert Landers wrote: > My personal opinion is that file-based type aliases would be the best. > It solves an immediate problem while introducing a problem most people > will never have (needing to reuse the type aliases elsewhere). It > allows them to be used in

Re: [PHP-DEV] Custom object equality

I am just going to put this out there, but I will vote against any RFC which provides access to userland to overload == and <=> until the base semantics of PHP comparisons are fixed and the necessary engine prerequisite work is done. I am working on such an RFC, as I frankly do not trust people

Re: [PHP-DEV] Peculiar behaviour of ext/xml set_X_handler() functions

On Tue, 10 Oct 2023 at 14:52, G. P. B. wrote: > Hello internals, > > While doing some refactoring of ext/xml to bring it up to modern engine > standards, I discovered some peculiar behaviour of the functions which set > callable handlers. > > The PR in question is: https://g

Re: [PHP-DEV] Better name for method Randomizer::nextFloat()

On Mon, 16 Oct 2023 at 09:34, Christian Schneider wrote: > > Side note: The implementation of nextFloat() is much more efficient than > that of getFloat(0.0, 1.0) and the output will differ even for the same > seeded engine. The domain of legal return values is identical. > > This sounds like an

[PHP-DEV] Peculiar behaviour of ext/xml set_X_handler() functions

Hello internals, While doing some refactoring of ext/xml to bring it up to modern engine standards, I discovered some peculiar behaviour of the functions which set callable handlers. The PR in question is: https://github.com/php/php-src/pull/12340 The issue is that this function doesn't just

Re: [PHP-DEV] Can we deprecate socket_set_blocking() ?

On Mon, 9 Oct 2023 at 18:39, Hans Henrik Bergan wrote: > The only thing socket_set_blocking() is good for is to confuse people > looking for socket_set_block() > Shouldn't we then also deprecate the socket_* alias functions? But this can probably be added to

Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

On Thu, 5 Oct 2023 at 07:40, Marc Bennewitz wrote: > I don't see a bug or broken behavior here as these functions were > processing floating point numbers since forever. > > https://3v4l.org/PrrmO > That's not my point, the point is about the function being broken for large 64bit integers,

Re: [PHP-DEV] proc_open() resource to opaque object migration

On Thu, 28 Sept 2023 at 21:20, Máté Kocsis wrote: > Hi Everyone, > > I'm writing in connection with a question coming up lately during the > "resource to opaque object migration" project ( > https://github.com/php/php-tasks/issues/6) which we have been working on > for quite a long while. > >

Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

On Tue, 26 Sept 2023 at 11:39, Marc Bennewitz wrote: > Hi internals > > I'd like to put a new RFC under discussion: > https://wiki.php.net/rfc/integer-rounding I don't understand the point of the deprecation phase at all. Frankly, I consider this RFC a bug fix of the current "broken"

Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

On Wed, 4 Oct 2023 at 23:23, Jorg Sowa wrote: > Thank you all for the discussion. I modified description of the RFC and > added deprecation of constants ROUND_UP and ROUND_DOWN from Intl extension > as an additional voting. > > Thanks also for input about possible mode ROUND_STOCHASTIC, however

Re: [PHP-DEV] Add bcround, bcfloor, bcceil to BCMath.

On Tue, 26 Sept 2023 at 11:10, Saki Takamachi wrote: > Hi, internals. > > I'm currently working on renovating the `round()` function. > > The current `round()` function rounds a value like 0.285 (0.28499) to > 0.29 using pre-round. > This is a mistake for FP, so discussions are underway to

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

On Tue, 29 Aug 2023 at 14:52, Saki Takamachi wrote: > Hi, internals. > > I thought about various things to improve the current situation where > `PDO::ATTR_ERRMODE` is not working very smartly. > > Exceptions may be thrown regardless of the setting of `PDO::ATTR_ERRMODE`. >

Re: [PHP-DEV] Removing support for the disable_classes INI setting

On Mon, 14 Aug 2023 at 20:03, Larry Garfield wrote: > However, I think it should not get an exception for code-freeze. At best, > I could see a deprecation warning on it in 8.3 and remove in 8.4/9, but I > defer to the RMs on that front. > In its current state, this INI setting does nothing

[PHP-DEV] Removing support for the disable_classes INI setting

Hello internals, While working on some DNF type bugs, I discovered some major issues around the disable_classes INI setting implementation. Such as: - A double-free of the type of a typed property - A use after free (which segfaults) when trying to access a property defined on a disabled class

Re: [PHP-DEV] New reflection methods for working with attributes

On Tue, 25 Jul 2023 at 21:55, Robin Chalas wrote: > FY I started working on the implementation., hopefully it will bring more > arguments in favor of that RFC which I’m willing to submit asap as well. > For future reference, please just open a PR with the implementation before writing an RFC

Re: [PHP-DEV] New reflection methods for working with attributes

On Tue, 25 Jul 2023 at 21:24, David Gebler wrote: > What's the difference between this and what was proposed in > https://externals.io/message/120799 ? I don't get why this wouldn't > require > an RFC. > Because it frankly doesn't require an RFC. I think people are getting confused as to when

Re: [PHP-DEV] [RFC] [VOTE] Deprecate remains of string evaluated code assertions

On Wed, 28 Jun 2023 at 17:09, G. P. B. wrote: > Hello internals, > > I'm opening the vote for the > Deprecate remains of string evaluated code assertions RFC: > https://wiki.php.net/rfc/assert-string-eval-cleanup > > It will last for two weeks and end on Wednesday the 12t

Re: [PHP-DEV] [RFC] [Vote] Path to Saner Increment/Decrement operators

On Wed, 28 Jun 2023 at 17:07, G. P. B. wrote: > Hello internals, > > I'm opening the vote for the Path to Saner Increment/Decrement operators > RFC: > https://wiki.php.net/rfc/saner-inc-dec-operators > > It will last for two weeks and end on Wednesday the 12th of July >

Re: [PHP-DEV] [VOTE] Interface Default Methods

On Mon, 3 Jul 2023 at 01:11, Levi Morrison wrote: > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to

[PHP-DEV] [RFC] [VOTE] Deprecate remains of string evaluated code assertions

Hello internals, I'm opening the vote for the Deprecate remains of string evaluated code assertions RFC: https://wiki.php.net/rfc/assert-string-eval-cleanup It will last for two weeks and end on Wednesday the 12th of July Best regards, George P. Banyard

[PHP-DEV] [RFC] [Vote] Path to Saner Increment/Decrement operators

Hello internals, I'm opening the vote for the Path to Saner Increment/Decrement operators RFC: https://wiki.php.net/rfc/saner-inc-dec-operators It will last for two weeks and end on Wednesday the 12th of July Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

I am going to group the response from the 3 emails. On Tue, 27 Jun 2023 at 09:17, Claude Pache wrote: > Although the specific comment in the php.ini file talks about runtime > switching, it is in fact irrelevant whether it is set at runtime or not. > More concretely; I use currently the

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

On Tue, 17 Jan 2023 at 14:28, G. P. B. wrote: > 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 > > The goal of this RFC is to reduce language complexity by

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

On Wed, 31 May 2023 at 13:08, G. P. B. wrote: > Hello internals, > > I would like to start the discussion about deprecating various remains > from the now removed string code evaluated assertions functionality of > assert(). > > The RFC is located on the wiki at the follo

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

On Wed, 31 May 2023 at 23:20, Claude Pache wrote: > Although your RFC says that the `zend.assertions` ini setting has > superseded `assert.active` for a while, the “official” php.ini file still > advises to modify the value of `assert.active` rather than the one of > `zend.assertion` in order to

Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function

On Thu, 1 Jun 2023 at 17:16, G. P. B. wrote: > Hello internals, > > The vote for the Define proper semantics for range() function RFC is now > open and will last for two weeks until the 15th of June 2023: > > https://wiki.php.net/rfc/proper-range-semantics > The vote has no

Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function

On Thu, 8 Jun 2023 at 07:35, Marc wrote: > sorry for speaking up so late but I think the following change is a > mistake and unexpected: > > > Calls to range() that have integer boundaries but a float step that > is compatible as an integer will now return an array of integers instead > of an

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Tue, 30 May 2023 at 09:54, Claude Pache wrote: > Any change that introduce a BC break or a migration burden must be > justified. (There has been enough rant around justified BC breaks, so let’s > not introduce unjustified ones.) > > What is the purpose of changing the return convention of

[PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function

Hello internals, The vote for the Define proper semantics for range() function RFC is now open and will last for two weeks until the 15th of June 2023: https://wiki.php.net/rfc/proper-range-semantics Best regards, George P. Banyard

[PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

Hello internals, I would like to start the discussion about deprecating various remains from the now removed string code evaluated assertions functionality of assert(). The RFC is located on the wiki at the following address: https://wiki.php.net/rfc/assert-string-eval-cleanup Initially, this

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

Hello Internals, Round 2, I'm planning to open voting tomorrow, the only change being is handling of string digits to behave like doing an ASCII string range: https://wiki.php.net/rfc/proper-range-semantics Any final comments or complaints should be raised now. Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

On Tue, 16 May 2023 at 17:49, Jorg Sowa wrote: > Thank you. That makes sense. I have last question about case with integer > and string digit, i.e. range('5', 10) or range('1', 9). What would be in > this case expected output? I couldn't find any test cases covering this > example. > I've added

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

On Mon, 15 May 2023 at 23:53, Jorg Sowa wrote: > Hello! > > I have one concern about the part: > > > Emit an E_WARNING when $start or $end is cast to an integer because the > other boundary input is a number or numeric string. (e.g. range > ('5', 'z'); or range

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Mon, 15 May 2023 at 19:39, Larry Garfield wrote: > Tangent: If I were to put together an RFC that set out such a 5 year cycle > expectation with reasonable guidelines around when things could be > deprecated, would anyone actually support it? > No, as this doesn't solve the problem. Best

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Mon, 15 May 2023 at 19:36, Rowan Tommins wrote: > On 15 May 2023 09:54:41 BST, "G. P. B." wrote: > > >Why are we assuming that PHP 9.0 is going to come after PHP 8.4? > > Historically, PHP has had a major release roughly every five years. The > main exce

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

On Mon, 15 May 2023 at 15:41, someniatko wrote: > The `PDOException` class is actually extending the `RuntimeException`, > not just `Exception`. > Yes, and this is, IMHO, a mistake. Outside SPL, there are only 4 extensions which extend from RuntimeException: - PDO - MySQLi - SNMP - Phar

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

Hello Internals, I plan to put the RFC to a vote tomorrow in its current state, which has not been changed since the 30th of March: https://wiki.php.net/rfc/proper-range-semantics Any final comments or complaints should be raised now. Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Sat, 13 May 2023 at 00:08, Larry Garfield wrote: > That means it's impossible to write code that works from 8.2 to 9.0 > without version checks. The overlap period is only 2 releases (8.3 and > 8.4). That's too short of a window. > Why are we assuming that PHP 9.0 is going to come after

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

On Fri, 5 May 2023 at 15:49, Derick Rethans wrote: > On Mon, 27 Mar 2023, G. P. B. wrote: > > > While working on analysing the impact of the changes proposed by > > amending the behaviour of the increment and decrement operators ( > > https://wiki.php.net/rfc/sa

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote: > > As a result of the pinning, function_exists() will return true for > functions in namespaces that have been pinned to a global function. > > The lookup pinning seems like the right way to optimise the > implementation, but I don't think it

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Mon, 10 Apr 2023 at 20:12, Anton Smirnov wrote: > 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

[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

Re: [PHP-DEV] Array spread append

On Thu, 6 Apr 2023 at 14:04, mickmackusa wrote: > I think it would be more intuitive to implement an array "appending" > functionality with "concatenating" syntax. The `.=` syntax already exists, > but is forbidden from use on non-strings. If you want to implement this > preexisting syntax as

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

On Thu, 30 Mar 2023 at 03:50, Mark Baker wrote: > On 28/03/2023 00:36, G. P. B. wrote: > > Hello internals, > > > > While working on analysing the impact of the changes proposed by amending > > the behaviour of the increment and decrement operators ( > > https

Re: [PHP-DEV] [IDEA] allow extending enum

On Wed, 29 Mar 2023 at 09:31, Rokas Šleinius wrote: > Enums were a very useful addition to PHP, however one aspect of them is > neither > explicitly documented - or seemingly even talked about. > > Enums were implemented as final so they cannot be extended nor can extend > anything else. > This

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

On Tue, 28 Mar 2023 at 08:29, Tim Düsterhus wrote: > Hi > > On 3/28/23 00:36, G. P. B. wrote: > > I therefore propose the "Define proper semantics for range() function" > RFC > > to address the unintuitive behaviour that sees no usage and/or hide bugs: > &g

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

On Tue, 28 Mar 2023 at 08:19, Christian Schneider wrote: > Am 28.03.2023 um 00:36 schrieb G. P. B. : > > I therefore propose the "Define proper semantics for range() function" > RFC > > to address the unintuitive behaviour that sees no usage and/or hide bugs: > &g

[PHP-DEV] [RFC] Define proper semantics for range() function

Hello internals, While working on analysing the impact of the changes proposed by amending the behaviour of the increment and decrement operators ( https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that the range() function has some rather lax behaviour that is very unintuitive. I

Re: [PHP-DEV] [RFC] [VOTE] Saner array_(sum|product)()

Hello internals, I am pleased to announce that the RFC was accepted unanimously, with 27 yes votes and 0 no votes. Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] Saner array_(sum|product)()

On Mon, 20 Feb 2023 at 14:38, Andreas Hennings wrote: > Hello, > the RFC seems like a good idea to me. > However, I do not see any mention of plus operator on arrays, e.g. ['a' => > 'A'] + ['b' => 'B']. The array_reduce() would support this, but I think > array_sum() would not, because of the

[PHP-DEV] [RFC] [VOTE] Saner array_(sum|product)()

Hello internals, I've just opened the vote for the Saner array_(sum|product)() RFC: https://wiki.php.net/rfc/saner-array-sum-product Best regards, George P. Banyard

Re: [PHP-DEV] What's the purpose of zend_result?

On Sun, 19 Feb 2023 at 08:45, Nikita Popov wrote: > On Sun, Feb 19, 2023, at 09:21, Max Kellermann wrote: > > On 2023/02/19 08:56, Nikita Popov wrote: > > > If you have a function like zend_stream_open_function(), SUCCESS and > FAILURE are directly meaningful values. > > > > Agree, but that

Re: [PHP-DEV] [RFC] Saner array_(sum|product)()

Hello internals, If there are no further feedback I intend on opening the vote for this tomorrow. Best regards, George P. Banyard

Re: [PHP-DEV] [VOTE] include cleanup

On Thu, 9 Feb 2023 at 22:09, Matthew Weier O'Phinney < mweierophin...@gmail.com> wrote: > I'm not directly involved in maintenance, but my take on the scenario was > that these were rejected and reverted because they caused breakage, whether > that was in compiling a spare PHP build, or in

Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments

On Tue, 7 Feb 2023 at 12:56, Côme Chilliet wrote: > Le vendredi 27 janvier 2023, 10:00:35 CET Andreas Heigl a écrit : > > Hey Folks. > > > > I think it would be a good idea to deprecate calling ldap_connect with 2 > > parameters host and port. > > Hello, > > My long term plan was to replace it

Re: [PHP-DEV] [RFC] Saner array_(sum|product)()

Hello internals, I've slightly updated the RFC: https://wiki.php.net/rfc/saner-array-sum-product I've added an FFI example which overloads addition but cannot be cast to a numeric type. And changed the behaviours around objects. An object needs to implement a numeric cast for it to be

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

On Fri, 20 Jan 2023 at 19:44, Jordan LeDoux wrote: > I don't see a section in the RFC about JIT or anything related to OpCache, > but I know from experience with the Operator Overloads RFC that there are > several architecture specific assembly optimizations for ++ and --. Have > these been

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

On Fri, 20 Jan 2023 at 18:28, Mark Baker wrote: > The documentation page consistently uses the word Increment and > Decrement, not Add 1 and Subtract 1. > > Developers who read the documentation should be aware of the Perl > convention when dealing with alphabetic strings, and should expect that

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

On Thu, 19 Jan 2023 at 00:23, Mark Baker wrote: > > 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 > >&

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

> been RFC's that required multiple tries to fly. > Possibly, and I could wait for the result of such an RFC, but I do not intend on pushing this forward. On Wed, 18 Jan 2023 at 15:32, Derick Rethans wrote: > On Tue, 17 Jan 2023, G. P. B. wrote: > > > I would like to st

Re: [PHP-DEV] [RFC] Saner array_(sum|product)()

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 ar

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

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

Re: [PHP-DEV] RFC: rules for #include directives

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

Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter

On Mon, 16 Jan 2023 at 15:36, Christian Schneider wrote: > Am 16.01.2023 um 14:39 schrieb G. P. B. : > > On Sun, 15 Jan 2023 at 20:58, Christian Schneider > wrote: > > Some comments: > > - I am not convinced that we should introduce a third way of providing > paramet

[PHP-DEV] [RFC] Saner array_(sum|product)()

Hello internals, 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 arrays and objects, and cast the

[PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

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 The goal of this RFC is to reduce language complexity by making $v++ behave like $v += 1 and $v-- behave like $v -= 1; I am expecting

[PHP-DEV] [PHP_DEV] [RFC] Add file_descriptor() function

Hello internals, I would like to start the discussion about the "Add file_descriptor() function" RFC: https://wiki.php.net/rfc/file-descriptor-function This RFC proposes the addition of the file_descriptor() function to retrieve the underlying file descriptor of stream if it exists. This is

Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter

On Sun, 15 Jan 2023 at 16:40, Nicolas Grekas wrote: > Hi George, > > There's quite some activity on the HTTP cookies side. > I read about SameParty and Partitioned attributes recently, see: > - https://developer.chrome.com/docs/privacy-sandbox/chips/ > - https://github.com/cfredric/sameparty > >

Re: [PHP-DEV] RFC: rules for #include directives

On Mon, 16 Jan 2023 at 12:03, Max Kellermann wrote: > Hi, > > in the past weeks, I submitted four PRs for cleaning up the #includes > in the PHP code base: > > https://github.com/php/php-src/pull/10216 > https://github.com/php/php-src/pull/10220 > https://github.com/php/php-src/pull/10279 >

[PHP-DEV] [RFC] Add SameSite cookie attribute parameter

Hello Internals, I would like to start the discussion about the Add SameSite cookie attribute parameter RFC: https://wiki.php.net/rfc/same-site-parameter This proposes to add an optional same site parameter to the setrawcooki(), setcookie() and session_set_cookie_params() that takes a a value a

Re: [PHP-DEV] Re: A set of 18 functions/changes to improve PHP core

On Fri, 6 Jan 2023 at 16:19, Christoph M. Becker wrote: > On 06.01.2023 at 17:01, Thomas Hruska wrote: > > > Pre-implemented as an extension (sort of) w/ a preliminary test suite to > > validate the implementations: > > > > https://github.com/cubiclesoft/php-ext-qolfuncs > > > > I probably

[PHP-DEV] What to do with opaque GMP objects which allows instantiation

Hello internals, While working on something, I was using GMP for a test case and creating it by doing akin to $o = new GMP(5); However, this does *not* create a GMP object initialized to 5, rather it creates and sets the value to 0. This is because it does not define a constructor, and the

Re: [PHP-DEV] PHP build for the wasm32-wasi target

On Thu, 22 Dec 2022 at 16:04, Rafael Fernández López wrote: > Hello community, > > I am reaching out on behalf of the WasmLabs team at the Office of the CTO > at VMware. > > We have been working on building PHP for WebAssembly, specifically for the > wasm32-wasi target. WASI [1] is a system

Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments

On Sat, 26 Nov 2022 at 23:06, Marco Pivetta wrote: > On Sat, 26 Nov 2022, 23:56 G. P. B., wrote: > >> As all the invariants will be maintained in the child classes >> > The invariant here is the immutability from a behavioural PoV. > LSP has 100% been broken in that ex

Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments

On Thu, 17 Nov 2022 at 14:47, Marco Pivetta wrote: > Hey Máté, > > On Tue, 15 Nov 2022 at 07:30, Máté Kocsis wrote: > > > Hi Everyone, > > > > Following Nicolas' thread about "Issues with readonly classes" ( > > https://externals.io/message/118554), we created an RFC to fix two > issues > >

[PHP-DEV] Removing OS2 specific code

Hello internal, While working on a bug, I've encountered some compatibility code for OS2, which I've planned to remove, as the last release of OS2 was in December 2001. This is to ask if anyone has any objections to removing compatibility for OS2. Best regards, George P. Banyard

[PHP-DEV] Should the engine be able to pass variables by reference of userland functions

Hello internals, While working on cleaning up the FCI/FCC API I stumbled upon the zend_fcall_info_args_ex() function. This function allows the engine to pass "variables" to userland functions that expect a by-ref parameter. This is currently only used within php-src in PDO when calling the

Re: [PHP-DEV] Experimental features

On Fri, 7 Oct 2022 at 07:57, Christian Schneider wrote: > But now to my main point: You are talking about the most simple and > isolated case, a new function. > I agree, and for most intent and purposes a function can be polyfilled in userland. So this is the least interesting case. However, I

Re: [PHP-DEV] Re: Increase maximum size of an uploaded file to 50Mbyte

On Wed, 7 Sept 2022 at 19:37, juan carlos morales < dev.juan.mora...@gmail.com> wrote: > By the Way... This needs an RFC right? > No it does not. Best regards, George P. Banyard

Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling

On Mon, 5 Sept 2022 at 18:20, Tim Düsterhus wrote: > Hi > > I've now written up an RFC as a follow-up for the "What type of > Exception to use for unserialize() failure?" thread [1]: > > > > RFC: Improve unserialize() error handling >

Re: [PHP-DEV] What type of Exception to use for unserialize() failure?

On Fri, 29 Jul 2022 at 18:17, Tim Düsterhus wrote: > Hi! > > I'm currently in the process of cleaning up the error handling of the > new ext/random and now came across the implementation of __unserialize(). > > Looking through the source code for existing examples I found that the > following is

  1   2   3   4   >