Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jul 8, 2024, at 12:03 PM, Alexandru Pătrănescu wrote: > Managed to simplify it like this and I find it reasonable enough: > function strtok2(string $string, ?string $token = null): string|false { > static $tokenGenerator = null; > if ($token) { > $tokenGenerator =

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

> On Jul 8, 2024, at 5:41 AM, Rowan Tommins [IMSoP] > wrote: > I agree. I wrote most of the below a couple of days ago, but I don't think it > posted correctly, so apologies if some people see it twice: > > Autoloading is just a way to load files later, by the engine telling you when > a

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

Howdy people, > On Jul 1, 2024, at 10:01 AM, Richard Miles wrote: > > Hey Larry, > >>> interface iArrayA ['a' => string ] >>> interface iArrayB extends iArrayA ['b' => string, 'c' => ?string, ‘d’ >>> => SomeClass, ‘e’=> iArrayA, ‘f’ => mixed ] >>> $array = (iArrayA &| iArrayB) [ ‘a’ =>

Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages

El El dom, 30 de jun. de 2024 a la(s) 11:52, juan carlos morales < dev.juan.mora...@gmail.com> escribió: > > > El El dom, 30 de jun. de 2024 a la(s) 11:15, Tim Düsterhus < > t...@bastelstu.be> escribió: > >> Hi >> >> On 6/30/24 15:43, juan carlos morales wrote: >> > So, what I see here in my

Re: [PHP-DEV] pcntl_exec update proposal

On Mon, Jul 8, 2024 at 11:14 PM Dusk wrote: > On Jul 8, 2024, at 14:12, David CARLIER wrote: > > Through this existing PR, I wanted to know how would appeal to you > adding some access restriction upon this existing call, using the open > basedir check. So if the sysadmin wants the php user

Re: [PHP-DEV] pcntl_exec update proposal

On Jul 8, 2024, at 14:12, David CARLIER wrote: > Through this existing PR, I wanted to know how would appeal to you adding > some access restriction upon this existing call, using the open basedir > check. So if the sysadmin wants the php user having no business calling > `/bin` commands for

[PHP-DEV] Re: [RFC] Static class

On 07/07/2024 21:08, Bilge wrote: On 24/06/2024 00:10, Bilge wrote: Hi Internals! I am excited to announce the final implementation for Static Class is ready for review at and includes a brief summary of the key semantics of the feature.

[PHP-DEV] pcntl_exec update proposal

Hi, Through this existing PR , I wanted to know how would appeal to you adding some access restriction upon this existing call, using the open basedir check. So if the sysadmin wants the php user having no business calling `/bin` commands for examples

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Mon, Jul 8, 2024 at 2:42 AM Rowan Tommins [IMSoP] wrote: > > > On 8 July 2024 04:25:45 CEST, Jordan LeDoux > wrote: > >I think it's strange that this discussion has driven deep down the tangent > >of versioning... > [...] > >Things like separating global scope between importer and importee,

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Le 6 juil. 2024 à 03:22, Mike Schinkel a écrit :On Jul 5, 2024, at 1:11 PM, Claude Pache wrote:Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit :https://wiki.php.net/rfc/deprecations_php_8_4* About strtok(): An exact replacement of `strtok()` that is

Re: [PHP-DEV] [RFC] Static class

On 08/07/2024 15:13, Alexandru Pătrănescu wrote: But I understand that once a class is static, all the chain of inheritance should be made of static classes, going up or down (and I would also think we can add interfaces and traits.). Correct. If interfaces are not included, do we allow

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Fri, Jun 28, 2024 at 3:38 PM Máté Kocsis wrote: > Hi Everyone, > > I've been working on a new RFC for a while now, and time has come to > present it to a wider audience. > > Last year, I learnt that PHP doesn't have built-in support for parsing > URLs according to any well established

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Mon, Jul 8, 2024 at 6:43 PM Alexandru Pătrănescu wrote: > > I'm hoping this can be simplified further, but to get to the point, I also > think we should have a userland replacement suggestion in the RFC. > > Managed to simplify it like this and I find it reasonable enough: function

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Sat, Jul 6, 2024 at 4:25 AM Mike Schinkel wrote: > > On Jul 5, 2024, at 1:11 PM, Claude Pache wrote: > > Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit : > https://wiki.php.net/rfc/deprecations_php_8_4 > > > * About strtok(): An exact replacement of `strtok()` that is reasonably >

Re: [PHP-DEV] [RFC] Static class

On Mon, Jul 8, 2024 at 3:22 PM Bilge wrote: > On 08/07/2024 12:48, Alexandru Pătrănescu wrote: > > > If we support inheritance for static classes, we should allow static on > both interface and abstract classes. > > What do you mean by *allow static on [...] interface*? Are you saying you > also

Re: [PHP-DEV] [RFC] Static class

On 08/07/2024 12:48, Alexandru Pătrănescu wrote: On Mon, Jul 8, 2024 at 1:12 PM Stephen Reay wrote: So really the question should be: why do you feel the need to *disallow* a combination that has no technical issues, and works already? If you're going to disallow abstract why

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 08/07/2024 05:04, Juliette Reinders Folmer wrote: > I'd suggest for an impact analysis/expected impact statement to be added to > the following deprecation proposals: > (...) > > And to a lesser degree for: > (...) > * Deprecate passing incorrect data types for options to ext/hash functions

Re: [PHP-DEV] [RFC] Static class

On Mon, Jul 8, 2024 at 1:12 PM Stephen Reay wrote: > > > So really the question should be: why do you feel the need to *disallow* a > combination that has no technical issues, and works already? If you're > going to disallow abstract why not disallow any class inheritance at all? > Because

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 08/07/2024 01:12, Gina P. Banyard wrote: > On Friday, 5 July 2024 at 18:11, Claude Pache wrote: >> * I don’t see the point of deprecating DOMImplementation::getFeature() >> instead of just removing it? “DOMImplementation::getFeature() is deprecated, >> throw manually an Error exception

Re: [PHP-DEV] [RFC] Static class

> On 8 Jul 2024, at 14:42, Bilge wrote: > > On 08/07/2024 01:16, Mike Schinkel wrote: >> Congrats on getting it to this point. > Thanks. It's been an adventure :^) > >> I support this in all but the RFC's restriction on `abstract`, as I have >> previously mentioned on the list. > I must have

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On 8 July 2024 04:25:45 CEST, Jordan LeDoux wrote: >I think it's strange that this discussion has driven deep down the tangent >of versioning... [...] >Things like separating global scope between importer and importee, managed >visibility of symbols and exports from modules/packages, allowing

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

On Sun, Jul 7, 2024 at 8:19 PM Saki Takamachi wrote: > Hi Juliette, > > > Hi Saki, > > > > Just wondering: why `int|string` instead of `float|string` ? > > In my experience, floats are the more pertinent type for which to use > the BCMath extension. > > > > Smile, > > Juliette > > Since floating

Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs

On Wed, 24 Jan 2024 г. at 14:01, Ilija Tovilo wrote: > Hi Sara > > Thank you for your feedback. > > On Tue, Jan 23, 2024 at 8:41 PM Sara Golemon wrote: > > > > On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo > wrote: > > > > > I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC. > > >

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté, Fantastic RFC :) Le dim. 7 juil. 2024 à 11:17, Máté Kocsis a écrit : > Hi Ignace, > > As far as I understand it, if this RFC were to pass as is it will model >> PHP URLs to the WHATWG specification. While this specification is >> getting a lot of traction lately I believe it will

Re: [PHP-DEV] [RFC] Static class

On 08/07/2024 01:16, Mike Schinkel wrote: Congrats on getting it to this point. Thanks. It's been an adventure :^) I support this in all but the RFC's restriction on `abstract`, as I have previously mentioned on the list. I must have missed a key point here. Let's suppose we're