Re: [PHP-DEV] [RFC] Lazy Objects

Le ven. 12 juil. 2024 à 08:00, Rob Landers a écrit : > > > On Fri, Jul 12, 2024, at 01:40, Benjamin Außenhofer wrote: > > > > Am 11.07.2024, 20:31:44 schrieb Tim Düsterhus : > > Hi > > On 7/11/24 10:32, Nicolas Grekas wrote: > > > Many things are already possible in userland. That does not always

Re: [PHP-DEV] [RFC] Lazy Objects

Le jeu. 11 juil. 2024 à 20:31, Tim Düsterhus a écrit : > Hi > > On 7/11/24 10:32, Nicolas Grekas wrote: > >> Many things are already possible in userland. That does not always mean > >> that the cost-benefit ratio is appropriate for inclusion in core. I get > >> behind the two examples in the “Ab

[PHP-DEV] [VOTE] Static class

Hi Internals! I am pleased to announce my RFC: /Static class/ is now open for voting: The voting will run for just shy of 4 weeks to allow extra time during this busy period prior to code freeze. Kind regards, Bilge

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

Hey Ignace, Nicolas, Based on your request for adding support for RFC 3986 spec compatible parsing, I evaluated another library (https://github.com/uriparser/uriparser/) in the recent days in order to add support for the requested functionality. As far as I can tell, the results were very promisin

Re: [PHP-DEV] [RFC] Lazy Objects

Le ven. 12 juil. 2024 à 01:40, Benjamin Außenhofer a écrit : > > > Am 11.07.2024, 20:31:44 schrieb Tim Düsterhus : > >> Hi >> >> On 7/11/24 10:32, Nicolas Grekas wrote: >> >> > Many things are already possible in userland. That does not always mean >> >> > that the cost-benefit ratio is appropria

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

On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer wrote: > On 2-7-2024 20:05, Gina P. Banyard wrote: >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer >> wrote: >> >>> * While a number of proposals include an impact analysis (thank you!), a >>> significant number of the pro

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

On Mon, Jul 15, 2024, at 9:20 AM, Máté Kocsis wrote: > Hey Ignace, Nicolas, > > Based on your request for adding support for RFC 3986 spec compatible > parsing, > I evaluated another library (https://github.com/uriparser/uriparser/) > in the recent days > in order to add support for the requested

[PHP-DEV] [RFC] [Vote] Fix up BCMath Number Class / Change GMP bool cast behavior

Hi all, RFC: Fix up BCMath Number Class / Change GMP bool cast behavior has started voting. https://wiki.php.net/rfc/fix_up_bcmath_number_class Voting ends on 2024-07-30 00:00:00 UTC. Regards, Saki

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

On 08.07.2024 at 05:04, Juliette Reinders Folmer wrote: > On 2-7-2024 20:05, Gina P. Banyard wrote: > >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer >> wrote: >> >>> Other than that, I join the previously voiced objections to the >>> deprecation of `uniqid()`, `md5()`, `sha1()`, `m

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

On Mon, Jul 15, 2024, at 13:20, Gina P. Banyard wrote: > On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer > wrote: > > On 2-7-2024 20:05, Gina P. Banyard wrote: > >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer > >> wrote: > >> > >>> * While a number of proposals includ

[PHP-DEV] [Vote] Property Hook performance improvements

Hi all. I have just opened the voting on the property hook (performance) improvement RFC. https://wiki.php.net/rfc/hook_improvements With the readonly bits pushed out to later, this is probably the shortest RFC I have ever written. :-) Vote opens now, and will close in 2 weeks on 29 July. --

Re: [PHP-DEV] [RFC] Lazy Objects

Hi On 7/12/24 08:00, Rob Landers wrote: For what it’s worth, I see “resetAsLazy()” being most useful for unit testing libraries that build proxies. While this feature will remove most of the tricky nuances around proxies, it doesn’t make it any easier in generating the code for them, so that

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

On 15/07/2024 11:20, Máté Kocsis wrote: Hey Ignace, Nicolas, Based on your request for adding support for RFC 3986 spec compatible parsing, I evaluated another library (https://github.com/uriparser/uriparser/) in the recent days in order to add support for the requested functionality. As far

Re: [PHP-DEV] [RFC] Lazy Objects

Hi On 7/15/24 09:25, Nicolas Grekas wrote: Testing is actually a good domain where resetting lazy objects might open interesting use cases. This reminded me about zenstruck/foundry, which leverages the LazyProxyTrait to provide refreshable fixture objects

Re: [PHP-DEV] [RFC] Lazy Objects

Hi On 7/15/24 11:59, Nicolas Grekas wrote: With refactoring, we can fix all design issues in all softwares. Yet that's too theoretical and this is missing the point IMHO. What we want to provide is a complete coverage of the lazy object domain. Simplifying too much can lead to an incomplete solu

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

Hi On 7/8/24 07:25, Andreas Heigl wrote: I don't mind putting the work in when there is a good justification, but I don't see one for this deprecation. The only one I can see is cleaning up the codebase and removing duplicate methods. But the RFC definitely states that it is to "encourage user

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

Hi On 7/15/24 16:12, Rob Landers wrote: This always gets me. "safer" doesn't have a consistent meaning. For Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni extensions, it's also faster. The following is on a Intel i7-1365U: $ openssl speed md5 sha1 sha256 sha512 *sni

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

Hi On 7/15/24 15:56, Christoph M. Becker wrote: I do not, however, agree with the reasoning that a function (like uniqid()) is often used in a unsafe way (i.e. for purposes it has not been designed), and therefore should be deprecated/removed. There are likely a couple of developers who are eas

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

On Mon, Jul 15, 2024 at 4:31 PM Tim Düsterhus wrote: > > Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni > extensions, it's also faster. The following is on a Intel i7-1365U: > > > $ openssl speed md5 sha1 sha256 sha512 > > *snip* > > version: 3.0.10 > > built on: Wed Feb 21

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

On Mon, Jul 15, 2024, at 23:29, Tim Düsterhus wrote: > Hi > > On 7/15/24 16:12, Rob Landers wrote: > > This always gets me. "safer" doesn't have a consistent meaning. For > > Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni > extensions, it's also faster. The following is

Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers

On Thursday, 4 July 2024 at 14:52, Gina P. Banyard wrote: > Hello internals, > > I would like to formally open the discussion on an RFC I've been working on > for the past year: > https://wiki.php.net/rfc/container-offset-behaviour > Hello internals, Ilija did a review of the RFC and pointed

Re: [PHP-DEV] [RFC] Lazy Objects

On Mon, Jul 15, 2024, at 21:23, Tim Düsterhus wrote: > Hi > > On 7/12/24 08:00, Rob Landers wrote: > > For what it’s worth, I see “resetAsLazy()” being most useful for unit > > testing libraries that build proxies. While this feature will remove most > > of the tricky nuances around proxies, it