Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Jordi Boggiano]

On 07/06/2021 21:50, Björn Larsson wrote:

Den 2021-06-02 kl. 22:16, skrev Mike Schinkel:
My only comment/request/suggestion is to consider Mark Randall's 
suggestion to use `...?` instead, for the reasons he mentioned in his 
email to the list:


https://externals.io/message/114157#114666 



Plus Levi Morrison seemed to approve:

https://externals.io/message/114157#114667 



-Mike



I second this opinion. So is the "...?" syntax something that will
be considered?

As this was still not answered.. I would like to just drop a +1. I do 
find the symmetry of "...?" / "?" quite appealing too, ensuring that you 
always get a "?" to indicate a partial application.


If it's controversial, Mark Randall's idea of having it be a subvote 
sounds good to me to make sure the debate is closed once and for all. 
Ignoring it now to get another RFC trying to change the syntax in two 
months isn't helpful :)


Aside from that, also +1 on "good work everyone involved", this looks 
pretty solid now and I'm looking forward to the addition!


Best,
Jordi

--
Jordi Boggiano
@seldaek - https://seld.be

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Guilliam Xavier]

On Thu, Jun 10, 2021 at 7:32 PM Guilliam Xavier 
wrote:

>
>  Since `$null?->whatever(1, 'a')` currently always returns null without
> error, shouldn't `$null?->whatever(?, 'a')` return a closure (with a
> signature built from the placeholders only) that will return null when
> called (i.e. equivalent to `fn (mixed $arg1) => null` here)?
>

Ah, we can also see `$foo?->bar(?)` as simply "desugaring" to `$foo ===
null ? null : $foo->bar(?)`, so the current behavior makes sense too (and
maybe even "more")...  I guess I was confused to get a "null-implying
error" despite using a "null-safe" call syntax :s  (There's also the
possibility of not supporting it, but I guess that would be a lose-lose...)

-- 
Guilliam Xavier

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Dan Ackroyd]

On Thu, 10 Jun 2021 at 18:32, Guilliam Xavier  wrote:
>  Since `$null?->whatever(1, 'a')` currently always
> returns null without error, shouldn't `$null?->whatever(?, 'a')` return a
> closure (with a signature built from the placeholders only) that will
> return null when called (i.e. equivalent to `fn (mixed $arg1) => null`
> here)?

No.

The short circuiting should happen in the same place, no matter what
is to the right of the "?->".

Having the behaviour vary and sometimes not return null, would be
highly surprising.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Guilliam Xavier]

On Thu, Jun 10, 2021 at 4:34 PM Larry Garfield 
wrote:

> On Thu, Jun 10, 2021, at 3:17 AM, Guilliam Xavier wrote:
> > On Wed, Jun 2, 2021 at 7:47 PM Larry Garfield 
> > wrote:
> >
> > > https://wiki.php.net/rfc/partial_function_application
> >
> > for `$null === null`, is `$c = $null->bar(?);` / `$c =
> > $null::baz(?);` an immediate error, or only later when calling
> `$c($arg)`?
>
> That dies with "call to member function on null" when trying to create the
> partial:
>
> https://3v4l.org/E6MgK/rfc#focus=rfc.partials
>

That makes sense (eager evaluation of non-placeholder "arguments",
including the called-on object).


> > does it
> > support nullsafe calls, e.g. `$foo?->bar(?)`? and if yes, what is the
> > signature of the Closure when `$foo === null`?
>
> I just checked, and it... sort of supports nullsafe.  Rather, if you try
> to partial a method on a null object, you get null back for your closure.
> Then when you try to call it, you get a "cannot invoke null" error.
> Which... I think makes sense.
>
> cf: https://3v4l.org/4XeB3/rfc#focus=rfc.partials


Well I find that unexpected :/


> As a cute side effect, Joe pointed out you could do this:
>
> https://3v4l.org/ERRdY/rfc#focus=rfc.partials


So there's a "workaround", although I wouldn't call it precisely "cute"...


> I wouldn't really call that a feature, but more of a side effect of the
> implementation.  Please don't count on that behavior.
>

I'd rather not indeed ;)  Since `$null?->whatever(1, 'a')` currently always
returns null without error, shouldn't `$null?->whatever(?, 'a')` return a
closure (with a signature built from the placeholders only) that will
return null when called (i.e. equivalent to `fn (mixed $arg1) => null`
here)?

Thanks,

-- 
Guilliam Xavier

[PHP-DEV] Re: PHP 8.0.0alpha1 is available for testing

[Ben Ramsey]

Apologies for the subject line. It was a copy-pasta error. All other
messages to other mailing lists have the correct subject.

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

[Levi Morrison via internals]

On Thu, Jun 10, 2021 at 8:40 AM Pierre  wrote:
>
> Le 10/06/2021 à 16:16, tyson andre a écrit :
> > So I'm probably changing this to `ImmutableTraversable` as a short name for 
> > the functionality,
> > to make it clear arguments are eagerly evaluated when it is created.
> > (ImmutableSequence may be expected to only contain values, and would be 
> > confused with the ds PECL's 
> > https://www.php.net/manual/en/class.ds-sequence.php)
>
> Hello,
>
> And why not simply RewindableIterator ? Isn't it the prominent feature
> of it ?
>
> Agreed it's immutable, but a lot of traversable could be as well.
>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

All iterators are "rewindable", though of course not in practice. I
would avoid such names because we may eventually add an interface
which works as a "tag" to say "yes, I actually do support rewinding."

The property of being rewindable comes from it being cached. Maybe
`CachedAggregate`? Aggregates are data structures from which an
external iterator can be obtained, so it makes a bit more sense if
it's eager.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.0.0alpha1 is available for testing

[Patrick ALLAERT]

Le jeu. 10 juin 2021 à 17:46, Ben Ramsey  a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> PHP 8.1.0alpha1 has just been released and can be downloaded from:
> https://downloads.php.net/~patrickallaert
> Or use the git tag: php-8.1.0alpha1
>
> Windows binaries are available at: https://windows.php.net/qa/
>
> This is the first official release of the PHP 8.1 serial and includes
> an incredible amount of work.
> Please test it carefully, and report any bugs at https://bugs.php.net
>
> 8.1.0alpha2 should be expected in 2 weeks, i.e. on 24 Jun 2021.
> Hash values and PGP signatures can be found below or at
> https://gist.github.com/ramsey/3f57be524e4469343b3d7db332c048e0
>
> Thank you, and happy testing!
>
> Regards,
> Patrick Allaert & Ben Ramsey
>
> php-8.1.0alpha1.tar.bz2
> SHA256 hash:
> 38fb766220c4e18da24db404812d343d34bb16256e621c629aafa7395b5e72f6
> PGP signature:
> - - -BEGIN PGP SIGNATURE-
>
> iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmC/m44ACgkQGZ+d/vb/
> uv0SSxAAteA2Yy690Y1bp+TrsZ/zLKOxLb043zfsJp+Y5YyT2Gj3b9Esuvrh10JN
> kqLM2ZEg2jpjCIhknimhOsgqiO2SikqkeHI3h4zo5BReOwpjHeaTv2ty6cH+EgPl
> vA37pUXRIpcPlCDPxoNqEHlbsAD2paZB35HcrH57dYoRBUVGPbApwVxCVmNX+It+
> w4SSa3psI2lU6FLyZHAyATy6prsHwNol7CdsCjRIHxWSGO4XML6O4qJOomWL49Ye
> 47mF/x5w3fZJdqCZV4qf1+bJr4v0jhv/ya0KzcYS2aoNG3Cewf1ZeAepeIwiK4zp
> QnqNJ3+Rt5de5ObHzDi5XdCkccWvGwuu/+x649DNhqyheOQT5fTgTqQG2duawfxm
> c3qc4dESj6jxyAJSPPvsecW0FLoOPHG1UFbcRubMs5xzMEeQ4Un7EAH7HV0Y60yn
> GK5DBvausruDUSP7nNsIVFr/GVQHzwWsXv5e9acWaQWGalorM8G5VyyHSW5BXL/L
> ViHfHY+/HJU5i2o7M3219zbvpXNFS3qGjX8o+sRKGPmcpruA8UMi50CudNiZmiSv
> LaAGFkXVlp/sl68scE8JfEZogdx7wZOGvpL2po9jsW/MJQ/FRGW4gprw7SeFNnRW
> 9gOO5mxw6squM7ETrWIslpfJp7wDX2uRFQG/vKNacl0+nZyE4dM=
> =Bg08
> - - -END PGP SIGNATURE-
>
> php-8.1.0alpha1.tar.gz
> SHA256 hash:
> 279edf3226e562aedad5caf593782964c430a1ebfd367221e2488e54d1be3c74
> PGP signature:
> - - -BEGIN PGP SIGNATURE-
>
> iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmC/m48ACgkQGZ+d/vb/
> uv0bIQ/9GzoJohJ//0g3ha/1y3wpeY1LYqaOudNo79VkWPlKdkCeZvg8R3uwc7zs
> NRRjKtSW0jgX+DeH3A1/kb9NOLohwOeeN7o8G4avMaEPnQJ4o7wRy622BsL0HFby
> yWRdKsDworusOdSS86/GkSEO9QXOEgL75Gm8jNpJF6KOtzx5t9LmiFl2eke/J23y
> qc/sfYJqSn4JkZJw8g5HR8VMNiy72NGL+Im03OTgkudhZgNypVclutpG5rSso0kM
> EdbLfGowYKweZWSyFFLlWn5NQ8Wm2SOCSXOasZAlvj7KiySjYl/mKVKYaB3GHo8g
> o6mHv3y01AjBZqY7kjzdiK9Da0kUAOG/B8Upfi15AdmbgwpkZYiZGVJm9O9u5UNF
> 9gSbFGliLW2qPJl2L75pg2xfuU1UxeJCfjA5B6DxpBCy1uwmjPmmNEv+0dAn53bG
> i6mE/BiRPf9XwQOIPVzTOQQYmHHC+/OEXBku2o3y6Z2k4/X6lqmFMC8TZq5rFcDd
> yKPgqdSvRqg9RTbhe+cc/PSUZJQFywULc9fULzNYT2d+Vg3X7d3wdE3RwDwebXJD
> Jq394GDtETYZlZTKRtkAglq1yfGmtTKarYxrq2PlI0gIqtvNGHaEKtrA5WT7pe/P
> 3dgGWCRB2C4tAhCs18pl2nmD/yuizav1C2DSP9//F0Ghv7/kzSU=
> =hVRJ
> - - -END PGP SIGNATURE-
>
> php-8.1.0alpha1.tar.xz
> SHA256 hash:
> 131a81ef9e0d62ba3b5ed81d530a4ff38d256ff12acec243d6afb5b39a85cb79
> PGP signature:
> - - -BEGIN PGP SIGNATURE-
>
> iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmC/m48ACgkQGZ+d/vb/
> uv2QlxAAkwrvUXijCsWgTmRA7bs0k5kb4YF1z3mRwvcoOnBZO0YqIYV+Vwxx++rB
> qA5mZWM+cDnAn8DDQYGqNcr/hc61jmCFlB8r6Fom5x16ODXXEcVW6CclYCBRthO+
> TK2R7n3mAzpzM/8D2gFX8kZlQ+DYG25SKP12nr6oGTF5GNU0bBTPSKUNChi5tk7V
> Kh+uWYLg8AdUHOYRAzNTukqfg/CexHpwA/7CnP/6J4g35tXj3XVoMy5wRdiW/KeC
> 6EUrG7LOEGwhKO9oM94Y+C07ZWtKJXQYzBxIJ6DjDpO7PwfnsX4Hdp/Q0oQDdeOU
> JeZ2xtEvZs00xp9Gh/G9FjEDfOKZDPSSqbTSpFowAa14ekUzQmHB53m4Ptc4NzxI
> z2J8ueRCeu9DfzvMiKwG4RplOYSR3OUp0Paa9XAN2gg2CC/xyV8+VoBs/w+1Jzfz
> tRBHSlgHGTuEwAoHlHcnW8cZiyjx10N8Seaf66OkgV3L/ZwJTYA5AFcsMDe80rZA
> O5joaiVXkrFXchQivskmIShkfu/hBcrcXX2VXBdeWqJ2lulIgd9QQoA4jXvmGa5H
> PyFQqb7rcj4YyR3K3QGRXRbVZZOdi9gLbK6UiQXC8JdHLqjPXH8pLJBobwPEOSzA
> r9p/H2efBZt/e9tpO8jnr7kCFXVxb2Z5TVu0nZ66exQkOfM1byU=
> =um8X
> - - -END PGP SIGNATURE-
> -BEGIN PGP SIGNATURE-
>
> iQJDBAEBCAAtFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmDCMygPHHJhbXNleUBw
> aHAubmV0AAoJEPnDncC5aYVEAp0P/0Nq/iLOmBvLCaxmlaaCcHmJ7OJmOLRtUa9N
> YQF3UdpYQ4CSSL7W8EgrTRS3LuqAS7Ce0wleLNNeukqwfeqhmCdMIaSa07HmfJNF
> J5A/z7JezWlP6HQWqJSED8yX3P49Tav+MgR2aaOmgUv/j5MSETfy/9dxca4Nm++A
> DzDGTe2reBsRWfqB3V/dPbooFISpN51FCMbaNHHsuUKqBqvAd6tVYAO1l6b04RTc
> 5MhScsQy502BGDXWlc4M4vVqvUx0sYvu66i2nl0agkVwAtuGNtYYK8nu0oL0L7/a
> 3W1YlO4FAlOIgwI7ZtRtIGK7JLRJy9a1YjKNO1cZJMMnOM6fs7/5zJ8XTe2OoCzI
> 0W8nFw1wfoRLO9hy7OFoF2yxMSVsAVi3FkHFOXtccgRCPJ9U1Jmc4XjWCn+AHX6E
> jeOkXqdp+igzec1bH5tat5Ok01GlUzbVmDBRbZtfN8W0S4CDP6sRGImSak7uyUDB
> M23VteaWhL2qApuzgqyEnzg4ryQLegVfCkIZ4zFUhepy2bZdw9qWI3tchXvNGr1m
> 5gr23305MuS1s0AhR8MomBjtfb26yNosFPI7y9E8EvCwfXCeQ0e+JSMSGSPqaJJv
> ohlPx3jXBG+LLsiUOzW5evGhPtCRxzSpJBLplvu8b0xfxVj9UWtD8G1jWt8kL8rq
> dB1fg2T1
> =EGzC
> -END PGP SIGNATURE-
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Of course, the subject should have been "PHP 8.1.0alpha1 is available for
testing", but you all got that ;-)

Re: [PHP-DEV] Re: Allow combining arg unpacking and named args

[Levi Morrison via internals]

On Thu, Jun 10, 2021 at 7:14 AM Nikita Popov  wrote:
>
> On Tue, May 25, 2021 at 4:18 PM Nikita Popov  wrote:
>
> > Hi internals,
> >
> > Currently, argument unpacking (...$foo) cannot be combined with named
> > arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
> > ...$args) are rejected by the compiler.
> >
> > https://github.com/php/php-src/pull/7009 relaxes this by allowing
> > func(...$args, x: $y). The named arguments are required to come last,
> > because this automatically enforces the invariant that named arguments must
> > be sorted after positional argument.
> >
> > Are there any concerns with relaxing this restriction?
> >
>
> Any further feedback on this?
>
> Nikita

No objection. In my head I figured the unpack would come after named
parameters, but it makes sense that an unpack which can contain both
positional and named arguments would come between the positional and
named arguments.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 8.0.0alpha1 is available for testing

[Ben Ramsey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

PHP 8.1.0alpha1 has just been released and can be downloaded from:
https://downloads.php.net/~patrickallaert
Or use the git tag: php-8.1.0alpha1

Windows binaries are available at: https://windows.php.net/qa/

This is the first official release of the PHP 8.1 serial and includes
an incredible amount of work.
Please test it carefully, and report any bugs at https://bugs.php.net

8.1.0alpha2 should be expected in 2 weeks, i.e. on 24 Jun 2021.
Hash values and PGP signatures can be found below or at
https://gist.github.com/ramsey/3f57be524e4469343b3d7db332c048e0

Thank you, and happy testing!

Regards,
Patrick Allaert & Ben Ramsey

php-8.1.0alpha1.tar.bz2
SHA256 hash:
38fb766220c4e18da24db404812d343d34bb16256e621c629aafa7395b5e72f6
PGP signature:
- - -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmC/m44ACgkQGZ+d/vb/
uv0SSxAAteA2Yy690Y1bp+TrsZ/zLKOxLb043zfsJp+Y5YyT2Gj3b9Esuvrh10JN
kqLM2ZEg2jpjCIhknimhOsgqiO2SikqkeHI3h4zo5BReOwpjHeaTv2ty6cH+EgPl
vA37pUXRIpcPlCDPxoNqEHlbsAD2paZB35HcrH57dYoRBUVGPbApwVxCVmNX+It+
w4SSa3psI2lU6FLyZHAyATy6prsHwNol7CdsCjRIHxWSGO4XML6O4qJOomWL49Ye
47mF/x5w3fZJdqCZV4qf1+bJr4v0jhv/ya0KzcYS2aoNG3Cewf1ZeAepeIwiK4zp
QnqNJ3+Rt5de5ObHzDi5XdCkccWvGwuu/+x649DNhqyheOQT5fTgTqQG2duawfxm
c3qc4dESj6jxyAJSPPvsecW0FLoOPHG1UFbcRubMs5xzMEeQ4Un7EAH7HV0Y60yn
GK5DBvausruDUSP7nNsIVFr/GVQHzwWsXv5e9acWaQWGalorM8G5VyyHSW5BXL/L
ViHfHY+/HJU5i2o7M3219zbvpXNFS3qGjX8o+sRKGPmcpruA8UMi50CudNiZmiSv
LaAGFkXVlp/sl68scE8JfEZogdx7wZOGvpL2po9jsW/MJQ/FRGW4gprw7SeFNnRW
9gOO5mxw6squM7ETrWIslpfJp7wDX2uRFQG/vKNacl0+nZyE4dM=
=Bg08
- - -END PGP SIGNATURE-

php-8.1.0alpha1.tar.gz
SHA256 hash:
279edf3226e562aedad5caf593782964c430a1ebfd367221e2488e54d1be3c74
PGP signature:
- - -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmC/m48ACgkQGZ+d/vb/
uv0bIQ/9GzoJohJ//0g3ha/1y3wpeY1LYqaOudNo79VkWPlKdkCeZvg8R3uwc7zs
NRRjKtSW0jgX+DeH3A1/kb9NOLohwOeeN7o8G4avMaEPnQJ4o7wRy622BsL0HFby
yWRdKsDworusOdSS86/GkSEO9QXOEgL75Gm8jNpJF6KOtzx5t9LmiFl2eke/J23y
qc/sfYJqSn4JkZJw8g5HR8VMNiy72NGL+Im03OTgkudhZgNypVclutpG5rSso0kM
EdbLfGowYKweZWSyFFLlWn5NQ8Wm2SOCSXOasZAlvj7KiySjYl/mKVKYaB3GHo8g
o6mHv3y01AjBZqY7kjzdiK9Da0kUAOG/B8Upfi15AdmbgwpkZYiZGVJm9O9u5UNF
9gSbFGliLW2qPJl2L75pg2xfuU1UxeJCfjA5B6DxpBCy1uwmjPmmNEv+0dAn53bG
i6mE/BiRPf9XwQOIPVzTOQQYmHHC+/OEXBku2o3y6Z2k4/X6lqmFMC8TZq5rFcDd
yKPgqdSvRqg9RTbhe+cc/PSUZJQFywULc9fULzNYT2d+Vg3X7d3wdE3RwDwebXJD
Jq394GDtETYZlZTKRtkAglq1yfGmtTKarYxrq2PlI0gIqtvNGHaEKtrA5WT7pe/P
3dgGWCRB2C4tAhCs18pl2nmD/yuizav1C2DSP9//F0Ghv7/kzSU=
=hVRJ
- - -END PGP SIGNATURE-

php-8.1.0alpha1.tar.xz
SHA256 hash:
131a81ef9e0d62ba3b5ed81d530a4ff38d256ff12acec243d6afb5b39a85cb79
PGP signature:
- - -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmC/m48ACgkQGZ+d/vb/
uv2QlxAAkwrvUXijCsWgTmRA7bs0k5kb4YF1z3mRwvcoOnBZO0YqIYV+Vwxx++rB
qA5mZWM+cDnAn8DDQYGqNcr/hc61jmCFlB8r6Fom5x16ODXXEcVW6CclYCBRthO+
TK2R7n3mAzpzM/8D2gFX8kZlQ+DYG25SKP12nr6oGTF5GNU0bBTPSKUNChi5tk7V
Kh+uWYLg8AdUHOYRAzNTukqfg/CexHpwA/7CnP/6J4g35tXj3XVoMy5wRdiW/KeC
6EUrG7LOEGwhKO9oM94Y+C07ZWtKJXQYzBxIJ6DjDpO7PwfnsX4Hdp/Q0oQDdeOU
JeZ2xtEvZs00xp9Gh/G9FjEDfOKZDPSSqbTSpFowAa14ekUzQmHB53m4Ptc4NzxI
z2J8ueRCeu9DfzvMiKwG4RplOYSR3OUp0Paa9XAN2gg2CC/xyV8+VoBs/w+1Jzfz
tRBHSlgHGTuEwAoHlHcnW8cZiyjx10N8Seaf66OkgV3L/ZwJTYA5AFcsMDe80rZA
O5joaiVXkrFXchQivskmIShkfu/hBcrcXX2VXBdeWqJ2lulIgd9QQoA4jXvmGa5H
PyFQqb7rcj4YyR3K3QGRXRbVZZOdi9gLbK6UiQXC8JdHLqjPXH8pLJBobwPEOSzA
r9p/H2efBZt/e9tpO8jnr7kCFXVxb2Z5TVu0nZ66exQkOfM1byU=
=um8X
- - -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmDCMygPHHJhbXNleUBw
aHAubmV0AAoJEPnDncC5aYVEAp0P/0Nq/iLOmBvLCaxmlaaCcHmJ7OJmOLRtUa9N
YQF3UdpYQ4CSSL7W8EgrTRS3LuqAS7Ce0wleLNNeukqwfeqhmCdMIaSa07HmfJNF
J5A/z7JezWlP6HQWqJSED8yX3P49Tav+MgR2aaOmgUv/j5MSETfy/9dxca4Nm++A
DzDGTe2reBsRWfqB3V/dPbooFISpN51FCMbaNHHsuUKqBqvAd6tVYAO1l6b04RTc
5MhScsQy502BGDXWlc4M4vVqvUx0sYvu66i2nl0agkVwAtuGNtYYK8nu0oL0L7/a
3W1YlO4FAlOIgwI7ZtRtIGK7JLRJy9a1YjKNO1cZJMMnOM6fs7/5zJ8XTe2OoCzI
0W8nFw1wfoRLO9hy7OFoF2yxMSVsAVi3FkHFOXtccgRCPJ9U1Jmc4XjWCn+AHX6E
jeOkXqdp+igzec1bH5tat5Ok01GlUzbVmDBRbZtfN8W0S4CDP6sRGImSak7uyUDB
M23VteaWhL2qApuzgqyEnzg4ryQLegVfCkIZ4zFUhepy2bZdw9qWI3tchXvNGr1m
5gr23305MuS1s0AhR8MomBjtfb26yNosFPI7y9E8EvCwfXCeQ0e+JSMSGSPqaJJv
ohlPx3jXBG+LLsiUOzW5evGhPtCRxzSpJBLplvu8b0xfxVj9UWtD8G1jWt8kL8rq
dB1fg2T1
=EGzC
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Allow combining arg unpacking and named args

[Larry Garfield]

On Thu, Jun 10, 2021, at 8:14 AM, Nikita Popov wrote:
> On Tue, May 25, 2021 at 4:18 PM Nikita Popov  wrote:
> 
> > Hi internals,
> >
> > Currently, argument unpacking (...$foo) cannot be combined with named
> > arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
> > ...$args) are rejected by the compiler.
> >
> > https://github.com/php/php-src/pull/7009 relaxes this by allowing
> > func(...$args, x: $y). The named arguments are required to come last,
> > because this automatically enforces the invariant that named arguments must
> > be sorted after positional argument.
> >
> > Are there any concerns with relaxing this restriction?
> >
> 
> Any further feedback on this?
> 
> Nikita

I guess no one has concerns.  I'm fine with it.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

[Pierre]

Le 10/06/2021 à 16:16, tyson andre a écrit :

So I'm probably changing this to `ImmutableTraversable` as a short name for the 
functionality,
to make it clear arguments are eagerly evaluated when it is created.
(ImmutableSequence may be expected to only contain values, and would be 
confused with the ds PECL's https://www.php.net/manual/en/class.ds-sequence.php)


Hello,

And why not simply RewindableIterator ? Isn't it the prominent feature 
of it ?


Agreed it's immutable, but a lot of traversable could be as well.

Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Larry Garfield]

On Thu, Jun 10, 2021, at 3:17 AM, Guilliam Xavier wrote:
> On Wed, Jun 2, 2021 at 7:47 PM Larry Garfield 
> wrote:
> 
> > Hi folks.  After much off-list discussion, iteration, and consideration,
> > we have a new draft of PFA ready for review.
> >
> > The URL is the same:
> >
> > https://wiki.php.net/rfc/partial_function_application
> >
> 
> Hi, thanks all for the reworks!  I just thought to something: does it
> support nullsafe calls, e.g. `$foo?->bar(?)`? and if yes, what is the
> signature of the Closure when `$foo === null` (and does it make a
> difference if, inside a function, it was created as a local variable `$foo
> = null;` vs received as a typed parameter `?Foo $foo`)?

I just checked, and it... sort of supports nullsafe.  Rather, if you try to 
partial a method on a null object, you get null back for your closure.  Then 
when you try to call it, you get a "cannot invoke null" error.  Which... I 
think makes sense.

cf: https://3v4l.org/4XeB3/rfc#focus=rfc.partials

As a cute side effect, Joe pointed out you could do this:

https://3v4l.org/ERRdY/rfc#focus=rfc.partials

I wouldn't really call that a feature, but more of a side effect of the 
implementation.  Please don't count on that behavior.

I also discovered while checking that nullsafe differentiates between null and 
undefined.  That was unexpected, but not related to the topic at hand. :-)

> Related, for `$null === null`, is `$c = $null->bar(?);` / `$c =
> $null::baz(?);` an immediate error, or only later when calling `$c($arg)`?

That dies with "call to member function on null" when trying to create the 
partial:

https://3v4l.org/E6MgK/rfc#focus=rfc.partials

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

[tyson andre]

Hi Alex,

> > I've created a new RFC https://wiki.php.net/rfc/cachediterable adding 
> > CachedIterable,
> > which eagerly evaluates any iterable and contains an immutable copy of the 
> > keys and values of the iterable it was constructed from
> >
> > A heads up - I will probably start voting on 
> > https://wiki.php.net/rfc/cachediterable this weekend after 
> > https://wiki.php.net/rfc/cachediterable_straw_poll is finished.
> >
> > Any other feedback on CachedIterable?
> 
> Thanks for explaining 4 months ago about my concern.
> I think I understand the main real impact of an eager iterable cache vs a 
> lazy iterable cache from a functional point of view:
> - exceptions are thrown during construction vs during the first iteration
> - predictable performance also on the first iteration.
> 
> How did you gather the information that eager implementation is more valuable 
> than lazy one? I'm mostly curious also how to assess this as technically to 
> me it also looks the other way around. Maybe mention that in the RFC.
> I was even thinking that CachedIterable should be lazy and an 
> EagerCachedIterable would be built upon that with more methods. Or have it in 
> the same class with a constructor parameter.

One of the reasons was size/efficiency. Adding the functionality to support 
lazy evaluation would require extra properties to track internal state and 
extra checks at runtime, 
point to the original iterable and the functions being applied to that iterable 
- so an application that creates lots of small/empty cached iterables would 
have a higher memory usage.

Having a data structure that tries to do everything would do other things 
poorly 
(potentially not support serialization, use more memory than necessary,
have unintuitive behaviors when attempting to var_export/var_dump it, 
surprisingly throw when being iterated over, etc)

> Also, being able to have a perfect userland implementation, not very complex, 
> even considering the lower performance, is not that good for positive voting 
> from what I remember from history...

1. The userland polyfill included in the RFC is an incomplete implementation 
that only supports iteration. 
   It's meant to be as fast as possible at the cost of memory usage.
   It's not even an IteratorAggregate, doesn't support json encode, 
createFromPairs, and many other functions.
2. Virtually all of the spl iterables that don't deal with filesystems can be 
reimplemented in userland.
   (https://en.wikipedia.org/wiki/Turing_completeness)

   Even complicated extensions such as redis or memcached can be reimplemented 
in userland on top of sockets,
   but with higher cpu usage than native extensions 
(https://github.com/predis/predis/blob/main/FAQ.md#predis-is-a-pure-php-implementation-it-can-not-be-fast-enough)

   The benefit of having data structures internally is the fact that developers 
who learn them can use them in any project without adding dependencies
   (even in single file scripts) and that applications using CachedIterable 
would have much better performance 

Also, you and Levi have pointed out that iterable/iterator functionality is 
traditionally on-demand
(https://en.wikipedia.org/wiki/Lazy_evaluation) (e.g. iterables such as 
CallbackFilterIterator, RecursiveArrayIterator, etc)

As a result, I'm thinking CachedIterable is really not a good name for the 
eagerly evaluated data structure I'm proposing here,
and that there was confusion about how the data structure behaved when the name 
CachedIterable was suggested.
If functionality like that described in 
https://externals.io/message/114805#114792 was added, it could use the name 
CachedIterable instead.

So I'm probably changing this to `ImmutableTraversable` as a short name for the 
functionality,
to make it clear arguments are eagerly evaluated when it is created.
(ImmutableSequence may be expected to only contain values, and would be 
confused with the ds PECL's https://www.php.net/manual/en/class.ds-sequence.php)

Thanks,
Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecate ticks

[Nikita Popov]

On Tue, May 11, 2021 at 10:52 AM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to propose the depreciation of the ticks mechanism:
> https://wiki.php.net/rfc/deprecate_ticks
>
> I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> is a language change, even if not a particularly important one...
>
> Regards,
> Nikita
>

To cross post a comment from the PR, in
https://github.com/php/php-src/pull/6967#issuecomment-841344456 someone
mentions that they intercept and rewrite all included files to add
declare(ticks=N) in order to perform memory usage / performance monitoring.

Regards,
Nikita

[PHP-DEV] Re: Allow combining arg unpacking and named args

[Nikita Popov]

On Tue, May 25, 2021 at 4:18 PM Nikita Popov  wrote:

> Hi internals,
>
> Currently, argument unpacking (...$foo) cannot be combined with named
> arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
> ...$args) are rejected by the compiler.
>
> https://github.com/php/php-src/pull/7009 relaxes this by allowing
> func(...$args, x: $y). The named arguments are required to come last,
> because this automatically enforces the invariant that named arguments must
> be sorted after positional argument.
>
> Are there any concerns with relaxing this restriction?
>

Any further feedback on this?

Nikita

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre Joye]

On Thu, Jun 10, 2021, 2:32 PM Nikita Popov  wrote:

I'm not sure where you got the strange idea that "readonly" can refer to
> asymmetric visibility. The two syntactic approaches to asymmetric
> visibility that I'm aware of are "{ get; private set; }" in C# and "public
> private(set)" in Swift. Neither use the "readonly" terminology for this
> purpose. Using "readonly" to describe asymmetric visibility is semantically
> incorrect, as such properties are not, in fact, read-only.
>

I listed my refs in the initial reply :)

And some like .net updates their syntax for init only write. I suppose I
see it more as "from the outside of the class" and my personal usages are
like that too.

In any case, good rfc, naming perception is a details, important but a
details for first time users.



> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Guilliam Xavier]

On Wed, Jun 2, 2021 at 7:47 PM Larry Garfield 
wrote:

> Hi folks.  After much off-list discussion, iteration, and consideration,
> we have a new draft of PFA ready for review.
>
> The URL is the same:
>
> https://wiki.php.net/rfc/partial_function_application
>

Hi, thanks all for the reworks!  I just thought to something: does it
support nullsafe calls, e.g. `$foo?->bar(?)`? and if yes, what is the
signature of the Closure when `$foo === null` (and does it make a
difference if, inside a function, it was created as a local variable `$foo
= null;` vs received as a typed parameter `?Foo $foo`)?

Related, for `$null === null`, is `$c = $null->bar(?);` / `$c =
$null::baz(?);` an immediate error, or only later when calling `$c($arg)`?

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Thu, Jun 10, 2021 at 3:21 AM Pierre Joye  wrote:

> Good morning Larry,
>
> Thank you. Very good summary, maybe worth adding to the RFC :)
>
> On Wed, Jun 9, 2021 at 11:52 PM Larry Garfield 
> wrote:
>
> >  readonly would be a separate, independent feature/syntax.
>
> Yes, my thought is about self explanatory syntax matching common usage
> of the same syntax/keyword with other languages. In this case,
> readonly, it does not :)
>
> Absolutely not a big deal (one will google that more ;), however I do
> like some "consistency" across languages as we almost all rely on many
> and get used to syntax for very standard operations like this.
>

The usage of "readonly" as proposed follows the commonly accepted
interpretation in other languages (modulo details). Readonly properties
refer to properties that only allow initializing assignments, though what
exactly that means is language dependent (e.g. it can take the form of
"only assignments inside the constructor"). Both C# and TypeScript use
"readonly" in this manner.

I'm not sure where you got the strange idea that "readonly" can refer to
asymmetric visibility. The two syntactic approaches to asymmetric
visibility that I'm aware of are "{ get; private set; }" in C# and "public
private(set)" in Swift. Neither use the "readonly" terminology for this
purpose. Using "readonly" to describe asymmetric visibility is semantically
incorrect, as such properties are not, in fact, read-only.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Readonly properties

[Pierre Joye]

On Thu, Jun 10, 2021 at 11:08 AM Mike Schinkel  wrote:
>
> Hi Larry,
>
> Thanks for the response.
>
> > On Jun 9, 2021, at 12:51 PM, Larry Garfield 
wrote:
> >
> > Pierre and Mike:
> >
> > "Asymmetric visibility" as we keep referring to it would mean the
"implicit accessors only" version of this:
https://wiki.php.net/rfc/property_accessors
> >
> > That is, it would let you define public/private/protected for get and
set operations on a property separately from each other.
> >
> > There are three key differences between readonly and asymmetric
visibility as described there:
> >
> > * Asymmetric visibility would allow a property to be reassigned
multiple times from within a class, readonly would allow writing to it only
once when it's uninitialized.  Whether one of those is too-tight or
too-loose is a matter of opinion and context.
>
> When I read your statement I first thought you were wrong, but then I
re-read Nikitia's RFC[1] and realized that RFC stated the properties of an
object assigned to a readonly property *could* be updated, but *not* the
readonly property itself.

That's not related but an assignment by "reference" consequence. I think :)


>
> I wonder if I was the only one who read that mistakenly?
>
> Anyway, have either you or Nikita considered making a distinction between
'public readonly' and 'private readonly' such that one could disallow any
changes after initialization and the other could allow changes but only
within the class?

Better formulated than I tried :)

I would like to have the readonly keyword to make a property readonly
outside the class but read/write inside the class, together with
visibility it should cover pretty much all cases (parent class
included).

Init only could be a separate keyword (allows init only, inside the
class or outside the class being defined by the property visibility
attributes, protected, private or public).

I think users, and myself first when I read it, will have a hard time
translating "asymmetric" part of this whole thing (as in, if one
has to go to wikipedia to understand what something does instead of
what it looks like ;) ).

best,

--
Pierre

@pierrejoye