[PHP-DEV] tsrm question

Hello internals, Last night I went down a rabbit hole with Frankenphp: https://github.com/dunglas/frankenphp/pull/933 It isn't 100% clear to me what values `ts_resource(id)` holds and if it needs to be freed/allocated per request or per thread. The performance impact is huge to reallocate on e

Re: [PHP-DEV] tsrm question

On Wed, Jul 24, 2024 at 1:15 AM Rob Landers wrote: > Hello internals, > > Last night I went down a rabbit hole with Frankenphp: > https://github.com/dunglas/frankenphp/pull/933 > > It isn't 100% clear to me what values `ts_resource(id)` holds and if it > needs to be freed/allocated per request or

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

> On Jul 23, 2024, at 12:26 PM, Larry Garfield wrote: > > Hypothetical pattern matching example: > > $foo is ['a' => int, 'b' => $b, 'c' => mixed]; > > That would assert that there's 3 keys. "a" may be any integer (but only an > integer), "b" can be anything and will be captured to a variable

Re: [PHP-DEV] tsrm question

Hi Rob, On Wed, Jul 24, 2024 at 3:17 PM Rob Landers wrote: > > Hello internals, > > Last night I went down a rabbit hole with Frankenphp: > https://github.com/dunglas/frankenphp/pull/933 > > It isn't 100% clear to me what values `ts_resource(id)` holds and if it needs > to be freed/allocated p

Re: [PHP-DEV] tsrm question

On Wed, Jul 24, 2024, at 13:54, Pierre Joye wrote: > Hi Rob, > > > On Wed, Jul 24, 2024 at 3:17 PM Rob Landers wrote: > > > > Hello internals, > > > > Last night I went down a rabbit hole with Frankenphp: > > https://github.com/dunglas/frankenphp/pull/933 > > > > It isn't 100% clear to me what

Re: [PHP-DEV] tsrm question

On Wed, Jul 24, 2024, 7:06 PM Rob Landers wrote: > > The number of threads are static (at least for now), so we should def do > this. > > Long story short, the TSRM API is very flexible, how and when you > alloc/free rsrc is basically up to you. It is possible to keep some > around in the root th

Re: [PHP-DEV] tsrm question

On Wed, Jul 24, 2024 at 7:06 PM Rob Landers wrote: > > On Wed, Jul 24, 2024, at 13:54, Pierre Joye wrote: > > Hi Rob, > > > On Wed, Jul 24, 2024 at 3:17 PM Rob Landers wrote: > > > > Hello internals, > > > > Last night I went down a rabbit hole with Frankenphp: > > https://github.com/dunglas/fra

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

On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Grekas wrote: >> Otherwise, I'm quite looking forward to this. > > 🤞 Another thought that occurred to me. Given how lightweight it *looks* to be (may not actually be, but looks it), how much overhead would there be to having a compiled DI container tha

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

On Wed, Jul 24, 2024, at 16:02, Larry Garfield wrote: > On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Grekas wrote: > > >> Otherwise, I'm quite looking forward to this. > > > > 🤞 > > Another thought that occurred to me. Given how lightweight it *looks* to be > (may not actually be, but looks it), h

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

On Wed, Jul 24, 2024, at 16:13, Rob Landers wrote: > On Wed, Jul 24, 2024, at 16:02, Larry Garfield wrote: >> On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Grekas wrote: >> >> >> Otherwise, I'm quite looking forward to this. >> > >> > 🤞 >> >> Another thought that occurred to me. Given how lightwei

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

Le mer. 24 juil. 2024 à 16:05, Larry Garfield a écrit : > On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Grekas wrote: > > >> Otherwise, I'm quite looking forward to this. > > > > 🤞 > > Another thought that occurred to me. Given how lightweight it *looks* to > be (may not actually be, but looks it),

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

Hi, Le jeu. 18 juil. 2024 à 21:58, Tim Düsterhus a écrit : > Hi > > On 7/17/24 20:31, Nicolas Grekas wrote: > > A bit unrelated to the above topic: we've further clarified the RFC by > > addition restrictions to what can be done with lazy proxies. Namely, when > > the factory returns an object f

[PHP-DEV] Should PHP reserve a namespace for built-in classes?

What is the general feeling about reserving a namespace for PHP's built in classes? As the number of built-in classes grows over time, the chances of naming collisions with user classes will grow. When naming conflicts occur, they happen in an unexpected way, that does not make it readily obvio

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

Hi On 7/24/24 19:43, Nick Lockheart wrote: What is the general feeling about reserving a namespace for PHP's built in classes? see https://wiki.php.net/rfc/namespaces_in_bundled_extensions Best regards Tim Düsterhus

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

On Wed, 2024-07-24 at 19:51 +0200, Tim Düsterhus wrote: > Hi > > On 7/24/24 19:43, Nick Lockheart wrote: > > What is the general feeling about reserving a namespace for PHP's > > built > > in classes? > > see https://wiki.php.net/rfc/namespaces_in_bundled_extensions > > Best regards > Tim Düster

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

On Wed, Jul 24, 2024, at 16:28, Nicolas Grekas wrote: > > To Rob: proxying by interface can be implemented using regular code > generation so it's not a blocker. Symfony does it already, and will continue > to do it to cover the use case. I'm not sure what you mean, as the RFC makes it look t

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

Hi On 7/24/24 21:44, Nick Lockheart wrote: Thank you. I've read through the RFC and see it was approved. Is it too late to comment on this? My concern is that placing things into new and arbitrary namespaces as per the RFC is just a different variation on the global name problem. Commenting is

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

Le mer. 24 juil. 2024 à 21:44, Rob Landers a écrit : > > > On Wed, Jul 24, 2024, at 16:28, Nicolas Grekas wrote: > > > To Rob: proxying by interface can be implemented using regular code > generation so it's not a blocker. Symfony does it already, and will > continue to do it to cover the use cas

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

On Wed, Jul 24, 2024, at 22:45, Nicolas Grekas wrote: > > > Le mer. 24 juil. 2024 à 21:44, Rob Landers a écrit : >> __ >> >> >> On Wed, Jul 24, 2024, at 16:28, Nicolas Grekas wrote: >>> >>> To Rob: proxying by interface can be implemented using regular code >>> generation so it's not a bloc

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

On 2024-07-24 15:58, Peter Stalman wrote: On Mon, Jul 22, 2024 at 9:06 AM Derick Rethans > wrote: - Deprecate md5(), sha1(), md5_file(), and sha1_file() (just says "large   impact") About 1.2 million. https://github.com/search?q=%28md5+OR+md5_file+OR+sha1+OR

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

On Wed, 2024-07-24 at 22:02 +0200, Tim Düsterhus wrote: > > > I think a better solution would be to have one namespace for all > > bundled classes, so that a specific namespace is reserved in > > advance. > > Needing to prefix everything by \PHP or something like this would > provide for a terri

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

On Wed, Jul 24, 2024 at 3:03 PM Morgan wrote: > And they would still be available as hash("md5") and hash("sha1"); the > only reason they're called out as their own distinct functions today is > historical inertia. > Yes, I am aware of that, it's covered in the RFC and has been discussed. My iss