Re: [PHP-DEV] [RFC] [VOTE] is_literal
On Fri, 9 Jul 2021 at 11:49, Lauri Kenttä wrote: > is there a compelling reason why the internal names couldn't be marked > literal > (even if it's technically "wrong")? Hi Lauri, Just again quickly noting we’re only talking about ~0.43% difference, nothing major in any way. But we wanted to ensure developers didn't wonder why something was seen as a literal in one case, but not in another (we wanted to ensure consistency), because most people don’t know much about how the internals of PHP work - especially optimisations which are supposed to be kind of ‘invisible’ to developers. This change also helped when a couple of other compiler optimisations happen: https://wiki.php.net/rfc/is_literal#compiler_optimisations Craig
[PHP-DEV] Re: Fake Closure Comparison
The test included is quite comprehensive.
Cheers
Joe
On Friday, 9 July 2021, Larry Garfield wrote:
> On Fri, Jul 9, 2021, at 4:51 AM, Nikita Popov wrote:
> > On Fri, Jul 9, 2021 at 10:45 AM Joe Watkins wrote:
> >
> > > Morning internals,
> > >
> > > While discussing some of the details of the first class callable RFC,
> it
> > > became apparent that fake closures (created by Closure::fromCallable)
> are
> > > not currently comparable in a useful way.
> > >
> > > Although this is not directly related to the first class callable
> feature,
> > > it's likely that the proliferation of this kind of code will follow,
> so now
> > > seems like a good time to fix the problem.
> > >
> > > https://github.com/php/php-src/pull/7223
> > >
> > > Any objections to merging that in master ?
> > >
> >
> > To clarify: What this implements is that
> >
> > $strlen1 = Closure::fromCallable('strlen');
> > $strlen2 = Closure::fromCallable('strlen');
> > var_dump($strlen1 == $strlen2);
> > // bool(true) with this patch, previously bool(false)
> >
> > The same would also apply to the first-class callable syntax, i.e. after
> > this patch strlen(...) == strlen(...) would return true.
> >
> > Regards,
> > Nikita
>
> Seems reasonable on the surface. My main question is how far that
> extends. Does it work *only* for Closure::fromCallable()/FCC syntax? What
> if the argument is not a string? How deep does the comparison go for, say,
> objects and methods?
>
> class C {
> public function beep(string $a): string { return $a . 'beep'; }
> }
>
> $c1 = new C();
> $c2 = new C();
>
> $strlen1 = Closure::fromCallable([$c1, 'beep']);
> $strlen1b = Closure::fromCallable([$c1, 'beep']);
> $strlen2 = Closure::fromCallable([$c2, 'beep']);
>
> // What do these do?
> var_dump($strlen1 == $strlen1b);
> var_dump($strlen1 == $strlen2);
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Fake Closure Comparison
On Fri, Jul 9, 2021, at 4:51 AM, Nikita Popov wrote:
> On Fri, Jul 9, 2021 at 10:45 AM Joe Watkins wrote:
>
> > Morning internals,
> >
> > While discussing some of the details of the first class callable RFC, it
> > became apparent that fake closures (created by Closure::fromCallable) are
> > not currently comparable in a useful way.
> >
> > Although this is not directly related to the first class callable feature,
> > it's likely that the proliferation of this kind of code will follow, so now
> > seems like a good time to fix the problem.
> >
> > https://github.com/php/php-src/pull/7223
> >
> > Any objections to merging that in master ?
> >
>
> To clarify: What this implements is that
>
> $strlen1 = Closure::fromCallable('strlen');
> $strlen2 = Closure::fromCallable('strlen');
> var_dump($strlen1 == $strlen2);
> // bool(true) with this patch, previously bool(false)
>
> The same would also apply to the first-class callable syntax, i.e. after
> this patch strlen(...) == strlen(...) would return true.
>
> Regards,
> Nikita
Seems reasonable on the surface. My main question is how far that extends.
Does it work *only* for Closure::fromCallable()/FCC syntax? What if the
argument is not a string? How deep does the comparison go for, say, objects
and methods?
class C {
public function beep(string $a): string { return $a . 'beep'; }
}
$c1 = new C();
$c2 = new C();
$strlen1 = Closure::fromCallable([$c1, 'beep']);
$strlen1b = Closure::fromCallable([$c1, 'beep']);
$strlen2 = Closure::fromCallable([$c2, 'beep']);
// What do these do?
var_dump($strlen1 == $strlen1b);
var_dump($strlen1 == $strlen2);
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] is_literal
On 2021-07-07 12:23, Nikita Popov wrote: permanent interned strings, which will be predominantly (or entirely?) non-literal. At least it doesn't look to me like names of internal functions/classes/etc are considered literal. I think this may be problematic, in that now the permanent non-literal interned string in the function/class tables will be different from the per-request literal interned string used by user code to reference it. Just wondering, if this is a major performance problem, is there a compelling reason why the internal names couldn't be marked literal (even if it's technically "wrong")? It seems unlikely to get a function or class name accidentally in a SQL query and even less likely that user input was involved. -- Lauri Kenttä -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Fake Closure Comparison
Le 09/07/2021 à 10:45, Joe Watkins a écrit : Morning internals, While discussing some of the details of the first class callable RFC, it became apparent that fake closures (created by Closure::fromCallable) are not currently comparable in a useful way. Although this is not directly related to the first class callable feature, it's likely that the proliferation of this kind of code will follow, so now seems like a good time to fix the problem. https://github.com/php/php-src/pull/7223 Any objections to merging that in master ? Cheers Joe I don't see where I would actually compare callables, and I'm not an engine maintainer, but from my point of view, this patch makes sense. Regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Fake Closure Comparison
On Fri, Jul 9, 2021 at 10:45 AM Joe Watkins wrote:
> Morning internals,
>
> While discussing some of the details of the first class callable RFC, it
> became apparent that fake closures (created by Closure::fromCallable) are
> not currently comparable in a useful way.
>
> Although this is not directly related to the first class callable feature,
> it's likely that the proliferation of this kind of code will follow, so now
> seems like a good time to fix the problem.
>
> https://github.com/php/php-src/pull/7223
>
> Any objections to merging that in master ?
>
To clarify: What this implements is that
$strlen1 = Closure::fromCallable('strlen');
$strlen2 = Closure::fromCallable('strlen');
var_dump($strlen1 == $strlen2);
// bool(true) with this patch, previously bool(false)
The same would also apply to the first-class callable syntax, i.e. after
this patch strlen(...) == strlen(...) would return true.
Regards,
Nikita
[PHP-DEV] Fake Closure Comparison
Morning internals, While discussing some of the details of the first class callable RFC, it became apparent that fake closures (created by Closure::fromCallable) are not currently comparable in a useful way. Although this is not directly related to the first class callable feature, it's likely that the proliferation of this kind of code will follow, so now seems like a good time to fix the problem. https://github.com/php/php-src/pull/7223 Any objections to merging that in master ? Cheers Joe
