Re: [PHP-DEV] RFC [Discussion]: Closure self-reference

[Stephen Reay]

> On 4 Jun 2023, at 02:11, Dan Ackroyd  wrote:
> 
> Hi internals,
> 
> I'm now opening the discussion for the Closure self-reference RFC:
> https://wiki.php.net/rfc/closure_self_reference
> 
> This was previously discussed as a draft here:
> https://externals.io/message/112216#112216
> 
> Thank-you to KapitanOczywisty for the implementation.
> 
> cheers
> Dan
> Ack
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Hi Dan,

I quite like this idea, but, to (ab)use the analogy, the syntax bike shed 
definitely needs a few more sample tins.

The various syntax choices that introduce a new variable all seem like they can 
easily lead to developer confusion about where each of the two variables are 
actually defined and what is valid.. I can see plenty of “$closure = fn() as 
$closure => ….;` just because people are unsure.


Is there a syntax issue with e.g. `fn::self` / `function::self` for this? I 
realise this is mostly just a variation on `Closure::current()` but it “feels” 
a bit more natural, and has the added benefit that it *could* be extended to 
return a closure of **any** function, including regular named methods/functions 
etc in a later RFC, if there’s demand for it.



Cheers

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

Re: [PHP-DEV] [RFC] [Discussion] Clone with

[Stephen Reay]

> On 9 Jun 2023, at 07:11, Larry Garfield  wrote:
> 
> On Thu, Jun 8, 2023, at 5:39 PM, Stephen Reay wrote:
> 
>> Is there a specific reason `clone with (foo: $bar);` can’t simply pass 
>> the arguments given to with(), to the __clone() magic method?
>> 
>> It leaves the developer free to use the passed argument(s) or deep 
>> clone existing properties or a mix depending on what’s passed, and 
>> seems like it has the least “magic” or unknown behaviour in terms of 
>> when things happen.
>> 
>> Just a thought.  
> 
> I experimented with that a few years back.  The results showed it is actually 
> pretty awful in practice.
> 
> https://peakd.com/hive-168588/@crell/object-properties-part-2-examples
> 
> --Larry Garfield
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Hi Larry

Sure, that example __clone() isn’t exactly what I’d call short-and-sweet, but 
it absolutely solves the problem of: “what happens, in which order, when you do 
`clone ($foo) with (bar: ‘baz’, moo: ‘foo’);` on an object with a __clone() 
method. There is zero ambiguity there because it’s expressed in php the 
developer can see/debug/trace.

Also, consider that for classes that have no nullable properties, the __clone 
method could be a lot simpler than your example shows, e.g.:

function __clone(?string $bar = null, ?int $baz = null, ?ComplexObj 
$foo = null) {
$this->bar = $bar ?? $this->bar;
$this->baz = $baz ?? $this->baz;
$this->foo = $foo ?? clone ($this->foo);
}


If the property hooks RFC had already passed a vote, I’d suggest that some 
expansion of hooks could provide a cleaner solution here, but it hasn’t yet 
(and I understand it’s not desirable to tie the fate of one RFC to another so 
heavily) so here we are.



Cheers


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

Re: [PHP-DEV] [RFC] [Discussion] Clone with

[Larry Garfield]

On Thu, Jun 8, 2023, at 5:39 PM, Stephen Reay wrote:

> Is there a specific reason `clone with (foo: $bar);` can’t simply pass 
> the arguments given to with(), to the __clone() magic method?
>
> It leaves the developer free to use the passed argument(s) or deep 
> clone existing properties or a mix depending on what’s passed, and 
> seems like it has the least “magic” or unknown behaviour in terms of 
> when things happen.
>
> Just a thought.  

I experimented with that a few years back.  The results showed it is actually 
pretty awful in practice.

https://peakd.com/hive-168588/@crell/object-properties-part-2-examples

--Larry Garfield

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

Re: [PHP-DEV] [RFC] [Discussion] Clone with

[Stephen Reay]

Sent from my iPhone

> On 9 Jun 2023, at 02:33, Larry Garfield  wrote:
> 
> On Thu, Jun 8, 2023, at 6:15 PM, Nicolas Grekas wrote:
>>> On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote:
> On Tue, May 30, 2023, 19:39 Larry Garfield 
 wrote:
> 
>>> On Mon, May 29, 2023, at 11:22 PM, Máté Kocsis wrote:
 To be honest, the current behavior seemed like the natural choice
>>> for
>>> me, and I didn't really consider to execute the __clone() method
>>> after
>> the
>>> clone assignments.
>>> Do you have a use-case in mind when you need to forward-pass
 information
>> to
>>> __clone()?
>> 
>> Not a specific one off hand.  It's more a conceptual question.  `with`
 has
>> more contextual awareness than __clone(), so it should have "first
 crack"
>> at the operation, so that if necessary it can make changes that
 __clone()
>> can then respond to.  The inverse doesn't make sense.
>> 
>> The only reason for `with` to come after would be to allow `with` to
>> "override" or "undo" something that __clone() did.  Generally
>>> speaking,
 if
>> you have to undo something you just did, you shouldn't have done it in
 the
>> first place, so that's a less compelling combination.
>> 
>> This one isn't a deal breaker, but we should be sure to think it
>>> through
>> as it's kinda hard to reverse later.
>> 
> 
> To me so far also it was natural to assume that __clone is first and
>>> only
> after that the rest of the operations.
> But `with` operations, be it properties assignment or even a closure,
 would
> run in the context of the caller of clone and sometimes this might be
>>> run
> not from a method of the cloned class.
> 
> An example:
> There is a class that represents persons of a fictive country/planet.
> Each person has many properties but has also a first name and a last
>>> name
> and there is a rule: the two names must not start with the same letter.
> Both names cannot be changed as they are defined readonly.
> Creation of new persons can be done using new for new random properties
 or
> using clone to preserve existing properties. But in both cases the
>>> first
> name and last name are randomly chosen.
> If we want to control the last name value during clone that would be
> possible using the `with` operation but the logic to allocate a first
 name
> will only happen in `__clone()`method.
> 
> To be able to achieve this we must have __clone last, as there we have
 the
> internal validations, operations and also access to private/protected
> members that are not accesible from where clone is being called.
> 
> Regards,
> Alex
 
 I... could not understand that in the slightest.  Can you show it in
>>> code?
 
 
>>> 
>>> Sorry for that. Here you go: https://3v4l.org/JIBoI/rfc#vgit.master
>>> If __clone would be first, there is no way to enforce the rule that a
>>> person cannot have their first name starting with the same letter as last
>>> name.
>>> 
>> 
>> I'm not sure that's what __clone should be used for.
>> This looks like a perfect use case for property hooks, isn't it?
>> 
>> On my side, I would find it unexpected that __clone is called after because
>> that would break cloning expectations:
>> Imagine you have a __clone that does some deep cloning (a much more typical
>> scenario for this construct),
>> Let's say __clone() does $this->foo = clone $this->foo;
>> 
>> Imagine now that you do: clone $obj with (foo: $bar)
>> I'd expect $obj->foo === $bar after this. But if __clone is called after,
>> that won't be true, and I don't see how that could be "fixed" if we swap
>> the order. Would you?
>> 
>> Nicolas
> 
> Oh, interesting.  There's a nice example case.  To make it a bit more 
> concrete, and think aloud... 
> 
> class Pet {
>  public function __construct(
>public readonly string $name = 'Fluffy',
>  ) {}
> }
> 
> class Address { ... }
> 
> class Person {
>  public function __construct(
>public readonly Pet $pet,
>public readonly Address $address,
>  }
> 
>  public function __clone() {
>// Legal now thanks to a previous RFC.
>$this->address = clone ($this->address);
>  }
> }
> 
> $p = new Person(new Pet(), new Address(blah));
> 
> // The person gets a new pet.
> $p2 = clone $p with (pet: new Pet('Bonzo'));
> 
> In this case, the order of operations is irrelevant.
> 
> // The person moves.
> $newAddr = new Address(whatever);
> $p3 = clone $p2 with (address: $newAddr);
> 
> In this case, if the `with` happens first, then the new address object is 
> cloned needlessly, but that *probably* doesn't hurt anything.  But $newAddr 
> !== $p3->address.
> 
> If the `__clone()` happens first, then the existing address object is cloned 
> needlessly, but that *probably* doesn't hurt anything.  Because the 
> assignment happens 

Re: [PHP-DEV] [RFC] [Discussion] Clone with

[Larry Garfield]

On Thu, Jun 8, 2023, at 6:15 PM, Nicolas Grekas wrote:
>> On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote:
>> > > On Tue, May 30, 2023, 19:39 Larry Garfield 
>> > wrote:
>> > >
>> > >> On Mon, May 29, 2023, at 11:22 PM, Máté Kocsis wrote:
>> > >> > To be honest, the current behavior seemed like the natural choice
>> for
>> > >> > me, and I didn't really consider to execute the __clone() method
>> after
>> > >> the
>> > >> > clone assignments.
>> > >> > Do you have a use-case in mind when you need to forward-pass
>> > information
>> > >> to
>> > >> > __clone()?
>> > >>
>> > >> Not a specific one off hand.  It's more a conceptual question.  `with`
>> > has
>> > >> more contextual awareness than __clone(), so it should have "first
>> > crack"
>> > >> at the operation, so that if necessary it can make changes that
>> > __clone()
>> > >> can then respond to.  The inverse doesn't make sense.
>> > >>
>> > >> The only reason for `with` to come after would be to allow `with` to
>> > >> "override" or "undo" something that __clone() did.  Generally
>> speaking,
>> > if
>> > >> you have to undo something you just did, you shouldn't have done it in
>> > the
>> > >> first place, so that's a less compelling combination.
>> > >>
>> > >> This one isn't a deal breaker, but we should be sure to think it
>> through
>> > >> as it's kinda hard to reverse later.
>> > >>
>> > >
>> > > To me so far also it was natural to assume that __clone is first and
>> only
>> > > after that the rest of the operations.
>> > > But `with` operations, be it properties assignment or even a closure,
>> > would
>> > > run in the context of the caller of clone and sometimes this might be
>> run
>> > > not from a method of the cloned class.
>> > >
>> > > An example:
>> > > There is a class that represents persons of a fictive country/planet.
>> > > Each person has many properties but has also a first name and a last
>> name
>> > > and there is a rule: the two names must not start with the same letter.
>> > > Both names cannot be changed as they are defined readonly.
>> > > Creation of new persons can be done using new for new random properties
>> > or
>> > > using clone to preserve existing properties. But in both cases the
>> first
>> > > name and last name are randomly chosen.
>> > > If we want to control the last name value during clone that would be
>> > > possible using the `with` operation but the logic to allocate a first
>> > name
>> > > will only happen in `__clone()`method.
>> > >
>> > > To be able to achieve this we must have __clone last, as there we have
>> > the
>> > > internal validations, operations and also access to private/protected
>> > > members that are not accesible from where clone is being called.
>> > >
>> > > Regards,
>> > > Alex
>> >
>> > I... could not understand that in the slightest.  Can you show it in
>> code?
>> >
>> >
>>
>> Sorry for that. Here you go: https://3v4l.org/JIBoI/rfc#vgit.master
>> If __clone would be first, there is no way to enforce the rule that a
>> person cannot have their first name starting with the same letter as last
>> name.
>>
>
> I'm not sure that's what __clone should be used for.
> This looks like a perfect use case for property hooks, isn't it?
>
> On my side, I would find it unexpected that __clone is called after because
> that would break cloning expectations:
> Imagine you have a __clone that does some deep cloning (a much more typical
> scenario for this construct),
> Let's say __clone() does $this->foo = clone $this->foo;
>
> Imagine now that you do: clone $obj with (foo: $bar)
> I'd expect $obj->foo === $bar after this. But if __clone is called after,
> that won't be true, and I don't see how that could be "fixed" if we swap
> the order. Would you?
>
> Nicolas

Oh, interesting.  There's a nice example case.  To make it a bit more concrete, 
and think aloud... 

class Pet {
  public function __construct(
public readonly string $name = 'Fluffy',
  ) {}
}

class Address { ... }

class Person {
  public function __construct(
public readonly Pet $pet,
public readonly Address $address,
  }

  public function __clone() {
// Legal now thanks to a previous RFC.
$this->address = clone ($this->address);
  }
}

$p = new Person(new Pet(), new Address(blah));

// The person gets a new pet.
$p2 = clone $p with (pet: new Pet('Bonzo'));

In this case, the order of operations is irrelevant.

// The person moves.
$newAddr = new Address(whatever);
$p3 = clone $p2 with (address: $newAddr);

In this case, if the `with` happens first, then the new address object is 
cloned needlessly, but that *probably* doesn't hurt anything.  But $newAddr !== 
$p3->address.

If the `__clone()` happens first, then the existing address object is cloned 
needlessly, but that *probably* doesn't hurt anything.  Because the assignment 
happens second, $newAddr === $p3->address.

So I suppose that's a point in favor of __clone() first.

Another option could be to run `with` first, but then 

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

[Jakub Zelenka]

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

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

This is the first official release of the PHP 8.3 serial and includes
an incredible amount of work.
Please test it carefully, and report any bugs at
https://github.com/php/php-src/issues

8.3.0alpha2 should be expected in 2 weeks, i.e. on 22 Jun 2023.
Hash values and PGP signatures can be found below or at
https://gist.github.com/bukka/66530718f180092527a741d023492b23

Thank you, and happy testing!

Regards,
Jakub Zelenka & Eric Mann


php-8.3.0alpha1.tar.bz2
SHA256 hash:
cb931d09ebacd9c773baebd0d714153c657d6a3a5fc63a1c2fc67728d10efa3c
PGP signature:
-BEGIN PGP SIGNATURE-

iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZH9XRwAKCRAcB3ncXAqd
5J74AQDOoVwrpRbr4QA0+2u0+9BbZuB+BAkH/9oUy7cZN6uFCAD/XYWokZX30c61
GIl+K86bhuMG2vXVse7cSU6oFbYlaQ8=
=6ISB
-END PGP SIGNATURE-


php-8.3.0alpha1.tar.gz
SHA256 hash:
741a9da205a18a754902a39e3cd7c4e66ef2611975a0f94027be001b6a8ed020
PGP signature:
-BEGIN PGP SIGNATURE-

iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZH9XSAAKCRAcB3ncXAqd
5PMcAQCCMbygOFjdpjNchNZlRZDaacU/Ovk6VvZyoxaaKd8t5wEAn1o5DV6hEVLO
ZYelg2cy/rbJHuPMrqofOtW8VK//IAM=
=xV6X
-END PGP SIGNATURE-


php-8.3.0alpha1.tar.xz
SHA256 hash:
7df01cbae615cccdc01a811094a74326119080e1141988fd57aeefd6b751165c
PGP signature:
-BEGIN PGP SIGNATURE-

iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZH9XSAAKCRAcB3ncXAqd
5LlLAQCb7NKEbHMwJIyyfQNdcvGco0yksB5HcWF8sqDkBdttNQEArY/4JkNqVaGT
VHv1lTg7R6T6R79teUjv1/WpELOqbQw=
=TsW9
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.7 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.7. This is a security release.

All PHP 8.2 users are encouraged to upgrade to this version.

For source downloads of PHP 8.2.7 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Release Manifest:


Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.7.tar.bz2
SHA256 hash: 5bfb2a35c67921bdcadd5c90cb290ad7537d24da113a5e8bc2d646b02de7488f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmR/pXoRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzR8Q/+PSfv0gDyM/mxvCzKVygvUX8Ii2gxKw43
+lvs7EaXKYo8ydJunwXLcZ3UWkrfOOMR4IcImlxTfqCTz2S1c4i6n2kdM4eI4wFU
xij6+5Zjp0rFylj7Zwftt8LkSWeOPgeLyWdjp6aY5cWaxJLZovqWwyL6NdprYJ+L
yGjh9KszY8BezV0U1zVSFlU6x86o+p79wRkDq5ODmG6dkUQtL6qp3krWj+UJlCog
odNooMM4rJhdT2pjvljUTf0DwXdJLeQxhVlI3GAL2YF579YiXeY68QnSy+425JpS
xYNYqun75GdVpR1QFIy2sjuBSMrY0XGsDS6+61hEFp9QINc932XNCvUF6wkcMkQH
jKChaxvLV84bmItXPqaDqP7JzxU+FFo6z3IDO3OkWUFfm1VaMvEW544e8Ugv40UB
u+E3qx76gC8r1vjk5iiUOilW22VPnf/AJyNDmVOmzjwa/O95fFbUETSKyxR5zp7f
QwNHGYQVcEkbj5saGFwgtyfwep2OQD1nKdF8ToVWIEgYbJK7cF5u2M4gAK0Re/wx
nxDe6jlNVpOc2Jamq8ygJfSap2eWzahsPVIGQIDsNF2yoekI6+ElgCdUcbJjVrCr
3cDqUehBvV5OUjeHq/jEdrLn9tUf4BSRRRrR5SXfb0+Kh+PX0NPFjSpBTUyrwY4O
44rG4sRC5fU=
=UIV7
-END PGP SIGNATURE-


php-8.2.7.tar.gz
SHA256 hash: 7046f939f0e5116285341d55c06af1d50907e107ac2c70defc32ef880f88cde4
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmR/pXsRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxWkhAAqPST6+IajxD8W63zgI7MfzF6nBDvAQsw
Pu2aoPBwfgUY5tIV7Ud7lqW+4lfy6fKnGJYj5jgYMtKDwY2F3Ec+0Y0FuCa62DlH
ZGSTs7zJln0i4+Hdrcg+UIwAjVQleHz+lj2nFMKMmRP3sX2BRcaBpKVZHguRaoMM
q03aBs24T63Q01kVrOa8M0yqxJsw6RraI9tHRizRwRZ2QRPHT9nHlWsDx16kK7ka
lZd15fZ8szkB2fQcyXVk2AL3LXepRlAf2Atxo1ikiVcp3bJTxae30xJSo260NIWR
okZoTlhj2FVgjERVC+9HpX3UpnlZ2gnoIdcQxEX5lab3SlCvptx15YFg1//9HOig
wq3eDEg4hc238zjyaYAU9zPzzIC/pxLXbjtLp8eJdZ0v7NWwITjsytc4qQNgDBlR
c1LLbpMhqzeHgTjzWk4XRELNqYRtl7Pt62AwGrF5+gZtfhvQAFu8EyjseOcdx96H
lDVGXDvPf0CgkpxUswoP0aTbz/ohcYjU4Uz2uld1FRByB3Jq6Ptp0yAVoiPUOe7R
rjxzE23FivD+V5kpd0O4XNlm2IEe/VI0KzP5oFN+VjF1E3HynrL6K5oISIvlRaur
asulBxsKOgO2YIgBL8HsBx69lgNE5g9lHGB8DKia3Yn6IbBPp0rZTn4Leja7fn+P
0wdG/GBC1pg=
=lMgc
-END PGP SIGNATURE-


php-8.2.7.tar.xz
SHA256 hash: 4b9fb3dcd7184fe7582d7e44544ec7c5153852a2528de3b6754791258ffbdfa0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmR/pXsRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzuHw/+IXiF6sgROxqpQCJZRznd+8TJahTudktO
3vsoUqpLGnNOC1uDZt70zE4lrUMYCIlRF9wkUw74IMX6kVqPJTCoPCw44pL7kMg2
lRUC4D5melqlAk1fRLPGqEvwv0DtV7EZTjnGdg4A7XpQwEvdQTxcKtB/SsCcRBrt
BKAf+eiWQYee6P8/9825dxPt6rWjSmwLmhoETnKbB1wJPsNjOSs6LMRl+jRaor/V
CilkoLBN6EPEC9RDjkXKWnPNgscZfe+P6DE8nQhHpaQIWD2Oce463p1XWgveF88r
D0kXt03C+oXR0WYX+igqrglLJE+sHqETZMNbt97f91rvJxyF3+jQ0uYBxPtpusni
0xQjE5MzNEfunhwA6D5MjxhFZR0k20hPHfW/mn4RAxanE7voUntPVZknGOGbhw0Y
4+sG3Xqkg9Qrvv/zH8e8Lmlf2b4xjSHL/ZJ8DLi97mjGxz6UqPPE9rT/CC1ykwXw
ydKNfUCyk8i02bDxf9ru6atw82pGS5oWPh4Ll+sJCHHwh/SIB+d8ZZpbNSHAX+Kx
SD2okLUT4zC/If14VOAby4hqwA/fISFyvgudhNO/8Igq5/G4C9+84UNdGPKmG7SC
UsiXwymwmuFENREmLVe1UD6a7nbcw2xqdR896r86Jtd+od/JPRjDplsLHJvWqS7I
s4OcAY9NILs=
=wc+O
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function

[Marc]

On 08.06.23 13:16, G. P. B. wrote:

On Thu, 8 Jun 2023 at 07:35, Marc  wrote:


sorry for speaking up so late but I think the following change is a
mistake and unexpected:

  > Calls to range() that have integer boundaries but a float step that
is compatible as an integer will now return an array of integers instead
of an array of floats:

var_dump( range(1, 5, 2.0) );
/* New Behaviour */
array(3) {
[0]=>
int(1)
[1]=>
int(3)
[2]=>
int(5)
}
/* Current Behaviour */
array(3) {
[0]=>
float(1)
[1]=>
float(3)
[2]=>
float(5)
}

The problem I see with this is that the return type changes from float
to int "magically" based on the value of the step.
range(1, 5, 2.0) // list range(1, 5, 2.1) // list

In my opinion, no matter, if start, end or step is a float the result
should be a list.


A list is compatible and interpretable as a list so this only I
slight change in output and has effectively no BC break when using the
values generated by range().
Moreover, this change is needed to make calls such as range("a", "z", 3.0)
work as intended.
I.e. generating a list of characters instead of generating the list [0.0]
by attempting to cast the strings to floats.

Moreover, considering the return type is already pretty magical, supporting
this specific case would add even more complexity to the implementation,
and this has effectively no BC break, I will not change this detail.
More so that the RFC is currently in voting and cannot be amended.


Thanks for your explanation. Now it makes more sense to me.

Marc

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

[PHP-DEV] PHP 8.1.20 Released!

[Ben Ramsey]

The PHP development team announces the immediate availability of PHP
8.1.20. This is a security release.

All PHP 8.1 users are encouraged to upgrade to this version.

For source downloads of PHP 8.1.20 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Release Manifest:


Many thanks to all the contributors and supporters!

Ben Ramsey, Patrick Allaert, & Joe Watkins



php-8.1.20.tar.bz2
SHA256 hash: 
55578587514a2707500f85319e57c0d4df9b8803cdb26566595ac4bf459dc4dd

PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmR/u4UACgkQ+cOdwLlp
hURpIw/9FVw8lMtwpglion+/hq+NN41VmML7PNoR2EGCn1bdue4dJkK57rKaxDYG
LvANkFwEnypJY7NjQ+HTg61/dPe5hBEvjGrkfqiSdXEZnnhyH8BnjkIrh7eLjWTJ
jRXay+b8WbJbOMIJoHeEU+JW6cRMpGQMqPB5riJM7sfCQx4XrNVWdEq9mnErNt0g
jMPvNCjJE73kMdg5WMg9REV6FYo76pUW4Bh5aXu5X8WLUtWHu/1zwtllrAq4PsuZ
s0R7XM861SvAKQZzJEYdEiwm2TJwR1l/IGdJG0zQyF3yNXDennfin8FhiKJ0irPj
XZAlJE/ctzj9OsdczphB68l1XlIbNI8Q5iuyyHufl9yJ6KOq0s9BBEJ8PTPg7dtU
xJUTRvMToPS7Nz4xUtWf8gaoJPQ+9cPrSN5NHg1l01os6rmFPA/EcLXms+JNzXGb
YS3Mgsrg20fHEe+mQPI9BrVB2sa56uByh9++UdwdWUOItc/EjWzCwwQE3FvwmXaL
S+HN1n8MlYbxJBjqvOTsUF67a02IDIwUIOTTsv3HFjmjCVt9RH/9NZbF6T6pN6/K
9EMUGMWOOnA85oFsOFE+tUYgmUIuMEeZo2kqpP36BPOzfxZiIwWPMVd9LEb7gC7x
Z1vtGs2i4/vAsZkKPzVX/FS7mM2nTbm19KOcps04E2p8QDXVGgs=
=wW5t
-END PGP SIGNATURE-


php-8.1.20.tar.gz
SHA256 hash: 
b7d3e2a0c5bed37bb39e4627550d0ee5a4a600042b83c63037b0f5f84793cbe6

PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmR/u4YACgkQ+cOdwLlp
hUQhHRAAkFqmmvpK6pOcl6b+eAsfEAMHOqcGBmwVL8+T87KKA87A0aU7HYP7jtFU
K+i1WOV48Ed1w92t9x5mTq1cf1xkLQ+Q/bO804iyWPEmzpwU0YdbXqDWgbX3l7K3
49oAIXBibolwWlF/Mlg58/hWphULMjwpjKl7iiZfZuRS7Bm0MzMHTHkRIp2HPy9H
6S8Q/AOaQG3rSUSj0ghXZEwS8SL48iW+lcwvkJEfc1GErD/pcmsN8t4QjqqCFl6d
qPoZkloUwbrdX/NM6gX/FB6VdMNvRZqEmdu7amqjIic0jk8QDUjVlQ7IdHPzBBxr
vX4Sdhi7WL9z2SlELIOBorn2iglGrGHLNMTDjDxK17YKzPVEe/5f94RKUxTyzVaq
30cSMDwsDcKExfIYSoqsZSCI1GJNNyF9WcNSQb1/YjSSDH72AOxSx9DXpEGS2ORk
dcGysDK+nLAcEcC86cgRQBYlc8N+eyaSIEEPO/4hykxS0c4+0bUfBFWJNxGqIBwo
YvYkuR9+TX2OaRrFS3+T3la7zUrehqFPUriz/+ZomH2HG5o2tf99TtLNcu1AkgWV
kBHx5+cUxr+18SWpLU0UDp/ke/RuGU/sksX+Q7ciH3WhM+b4YDKoGZUFAucDGXwM
OOdxas2YvpNPjPLoO4hGLOkrQEwhFzYmEe5voa59FKy4xPmGHx0=
=NYlI
-END PGP SIGNATURE-


php-8.1.20.tar.xz
SHA256 hash: 
4c9973f599e93ed5e8ce2b45ce1d41bb8fb54ce642824fd23e56b52fd75029a6

PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmR/u4YACgkQ+cOdwLlp
hURGDw//R4dmZsdx4fbh2tLdpyJTsE9fjzFdWZ84HK7UsQsGO51zOn5nUs7iYasO
gfl0wpdje5G2S0c9cCXvfbKabx5WSCkb+gaWIWHOSWg0gnhUq62zA3NzWtPrutK5
83DfoWZRJKAQ3QwuE4uXLsVfdnXGL6Ei86J2zH8Dbr1J5xSlBmRVR7JpUvYGW8Kg
w/kUGlj179FCtabj5whcSOAee5SxFNe99oiLBWNC5Qr/7/AqOBz23rQEnTWVepg3
A39l+8RsRa/I8EZr1Xt4wD+P9k6lu2elYAt83LlmyhwdEverwRh6h4pvkOMro4ZF
2swLcbA/MFsM8Ka4bR6K08lBlxI3hXJTgXhtNXmjHofoZKCB70AwtQEL19VOBB5e
mma6on/D23K0bx2GDLpwdnTULOV4PnPccnkkQ4LIet0WUdXvyB9pCgt4Ubh67Xoj
DMB6INQPnEFeVh0xBt46mMoXQbsVjXdbD10NKyoBYZ9rZy7W8IsI/qnEgty7ZVfr
79vaUkoL22pBdYEmnHhKwj/Q6ZZP7VNZMOkw9EbXygzoZuB5T59HfbwJ32OZ/akf
VL0sUjvNX3TjgViY7nZKSWkIvQh2kgzB2e9+rXV3lngtkjWxHts5/83I7ri4RGU+
F8znKu3AebhJIJeLuHGfoLTeS8bhPGKDB55wC1a9CEmnLV4IOls=
=1N1J
-END PGP SIGNATURE-



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] [Discussion] Clone with

[Nicolas Grekas]

> On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote:
> > > On Tue, May 30, 2023, 19:39 Larry Garfield 
> > wrote:
> > >
> > >> On Mon, May 29, 2023, at 11:22 PM, Máté Kocsis wrote:
> > >> > To be honest, the current behavior seemed like the natural choice
> for
> > >> > me, and I didn't really consider to execute the __clone() method
> after
> > >> the
> > >> > clone assignments.
> > >> > Do you have a use-case in mind when you need to forward-pass
> > information
> > >> to
> > >> > __clone()?
> > >>
> > >> Not a specific one off hand.  It's more a conceptual question.  `with`
> > has
> > >> more contextual awareness than __clone(), so it should have "first
> > crack"
> > >> at the operation, so that if necessary it can make changes that
> > __clone()
> > >> can then respond to.  The inverse doesn't make sense.
> > >>
> > >> The only reason for `with` to come after would be to allow `with` to
> > >> "override" or "undo" something that __clone() did.  Generally
> speaking,
> > if
> > >> you have to undo something you just did, you shouldn't have done it in
> > the
> > >> first place, so that's a less compelling combination.
> > >>
> > >> This one isn't a deal breaker, but we should be sure to think it
> through
> > >> as it's kinda hard to reverse later.
> > >>
> > >
> > > To me so far also it was natural to assume that __clone is first and
> only
> > > after that the rest of the operations.
> > > But `with` operations, be it properties assignment or even a closure,
> > would
> > > run in the context of the caller of clone and sometimes this might be
> run
> > > not from a method of the cloned class.
> > >
> > > An example:
> > > There is a class that represents persons of a fictive country/planet.
> > > Each person has many properties but has also a first name and a last
> name
> > > and there is a rule: the two names must not start with the same letter.
> > > Both names cannot be changed as they are defined readonly.
> > > Creation of new persons can be done using new for new random properties
> > or
> > > using clone to preserve existing properties. But in both cases the
> first
> > > name and last name are randomly chosen.
> > > If we want to control the last name value during clone that would be
> > > possible using the `with` operation but the logic to allocate a first
> > name
> > > will only happen in `__clone()`method.
> > >
> > > To be able to achieve this we must have __clone last, as there we have
> > the
> > > internal validations, operations and also access to private/protected
> > > members that are not accesible from where clone is being called.
> > >
> > > Regards,
> > > Alex
> >
> > I... could not understand that in the slightest.  Can you show it in
> code?
> >
> >
>
> Sorry for that. Here you go: https://3v4l.org/JIBoI/rfc#vgit.master
> If __clone would be first, there is no way to enforce the rule that a
> person cannot have their first name starting with the same letter as last
> name.
>

I'm not sure that's what __clone should be used for.
This looks like a perfect use case for property hooks, isn't it?

On my side, I would find it unexpected that __clone is called after because
that would break cloning expectations:
Imagine you have a __clone that does some deep cloning (a much more typical
scenario for this construct),
Let's say __clone() does $this->foo = clone $this->foo;

Imagine now that you do: clone $obj with (foo: $bar)
I'd expect $obj->foo === $bar after this. But if __clone is called after,
that won't be true, and I don't see how that could be "fixed" if we swap
the order. Would you?

Nicolas

Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function

[G. P. B.]

On Thu, 8 Jun 2023 at 07:35, Marc  wrote:

> sorry for speaking up so late but I think the following change is a
> mistake and unexpected:
>
>  > Calls to range() that have integer boundaries but a float step that
> is compatible as an integer will now return an array of integers instead
> of an array of floats:
>
> var_dump( range(1, 5, 2.0) );
> /* New Behaviour */
> array(3) {
>[0]=>
>int(1)
>[1]=>
>int(3)
>[2]=>
>int(5)
> }
> /* Current Behaviour */
> array(3) {
>[0]=>
>float(1)
>[1]=>
>float(3)
>[2]=>
>float(5)
> }
>
> The problem I see with this is that the return type changes from float
> to int "magically" based on the value of the step.
> range(1, 5, 2.0) // list range(1, 5, 2.1) // list
>
> In my opinion, no matter, if start, end or step is a float the result
> should be a list.
>

A list is compatible and interpretable as a list so this only I
slight change in output and has effectively no BC break when using the
values generated by range().
Moreover, this change is needed to make calls such as range("a", "z", 3.0)
work as intended.
I.e. generating a list of characters instead of generating the list [0.0]
by attempting to cast the strings to floats.

Moreover, considering the return type is already pretty magical, supporting
this specific case would add even more complexity to the implementation,
and this has effectively no BC break, I will not change this detail.
More so that the RFC is currently in voting and cannot be amended.

Best regards,

George P. Banyard

[PHP-DEV] PHP 8.0.29 Released

[Gabriel Caruso]

The PHP development team announces the immediate availability of PHP
8.0.29. This is a security fix release.

All PHP 8.0 users are advised to upgrade to this version.

For source downloads of PHP 8.0.29 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_0_29.php
Downloads: https://php.net/downloads#v8.0.29
Windows downloads: https://windows.php.net/download#php-8.0
Changelog: https://php.net/ChangeLog-8.php#PHP_8_0
Release Manifest: <
https://gist.github.com/carusogabriel/23a65f8c273d1ebedececeba1f60a416> and
below;

Thanks to everyone that worked on getting the security patch ready for
today.

Gabriel Caruso & Sara Golemon

php-8.0.29.tar.gz
SHA256 hash:
db6ee08df5706365f624cde1cffb20ad6de1effe59d7e886337213a09f2e2684
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEELBbHZdvlSgiBMPG8S5tfYAtV87QFAmSAwTgWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRBLm19gC1XztA53D/0RJF8lvQaMdUNMIcMTc4lveHO6
AhZzaB4I7OTd3XfgJ5LAaiQNvJI4YuSWDsbq7oJd8YrcUW4obfFhPCsxoSVehwis
Hb7oeX3QwieCkhRPoJBxIH3bSC9+c1mIKq4+JzgbVxwX/FrrRRYf7coAyFmUxFy/
m7gPKsHwCnXXevIhKpsaLDTS1gsL7Qtk0NvA5y63apjwMGr8qN2GygrxUc5xkFpa
Rk4OBSzfcF97Rx5qt/9IO85qPLor69253oQzDNopXcJ4+mxeeTc9M6/mOhQVgPCg
q5EAjPmNhqwV3Dyi7iq26TN5O7CY+SomTlvd1q+kqdNuDYjfpm4RNctNVokMLrM/
Gx4Drk7FMPBk30PTK+NHA5OXmdOE7B2WL/IiEsDnCVw5GijWJvVn71bDbE50oI1D
d84uBQFxtO8bAZbZnnks840j6uTUHayc5P6i9nYKq2HkvFXcGVROaOf76xoeBGoy
QCeSCgn/HwrpeqUd1KtTalBctyQx1rRa+Y1TF1s2QpApIkAbo3H7U2q3QwT/Zh1f
7SS3P4tr7sm2RZomUMGtJtK6Z5dB+GYg9iJR8HUfgdaWX463IWUIUHwU7WWdRG19
7fHj6MA9k+qdDxIhfiIw7tuXushV9PUhZG24RkK420vTuyudnUVvqkwgAgNatwJ5
0aAB/7itUwZZWhtRKg==
=Z8JQ
-END PGP SIGNATURE-

php-8.0.29.tar.bz2
SHA256 hash:
4801a1f0e17170286723ab54acd045ac78a9656021d56f104a64543eec922e12
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEELBbHZdvlSgiBMPG8S5tfYAtV87QFAmSAwUMWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRBLm19gC1XztBTCEACqRxziyfTC0ULgFjrXi4uiDuGH
Xj8wA4OS7T09rYKJXgxrbTbKLMkNHT1lMHX3Jz6Mj4pcZliQzyuqraNd40TkC44H
gjrK8a/hWBkO5a30M67cXUV3/hEjr7DFcxmcOmH0kzkgm/Bu3kANu7OhZ56G/ZNJ
Mtq7oIA0xy/CyAbwYiOEsitrKuaO+TvhnlePqsr3ZbITJlwh3dfdivxEw8N+eJcW
OileGvr/z9DPg0IRhg7fGFNB2CA8cqwfhiODxYgzzW2EW0q4DHNYyGzSVXK/yo+0
+6bT75jaI4XAskiSCuUaOys+n+h+12oO9DF6T8Twz7qSFGoAMFfiHA3410T8AmcS
rhdTXI3Gsn7vQhTXVV3Jjw4d2L8qAVGn6nkh/XsowDid6BVIfxHqzkFaKIkghdeM
WoJtSQl55JDEElf5MhWLUbmE7yAQ+qE1iWIKt18XP9Cr7bUoic4MTpVv9XIahyFR
Ob5osaH/od2lnkfXt1JN4IKhQncdExM6n5x9LVWQy6rWl+d5OqmwELOe0iPUY7sZ
3f8/mjcxHft/tCu1rLRRYGC1saEfTwT+/S1WIxoqQo5TCTkcZERPqEdB4NePdRkn
ctSvANoQHawQJKM4zzb6GirjnJSz5bxUOn0hZShsX56Cyp/8064PJg7naqIoPheY
2Qd8hKjunN9r5tmM9Q==
=nqWP
-END PGP SIGNATURE-

php-8.0.29.tar.xz
SHA256 hash:
14db2fbf26c07d0eb2c9fab25dbde7e27726a3e88452cca671f0896bbb683ca9
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEELBbHZdvlSgiBMPG8S5tfYAtV87QFAmSAwUMWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRBLm19gC1XztKXJEACZBnsPtLMvW+2CTx5jx8YPG5im
WpDVu/AshXd330OONh052R5aadhmhLIIZ36NGz0qVwEvq+FkHlYRWsCR1RnqbBfP
3NLgWkoG1WKBbJW4qqA5oJ7ch8uSdQdrEiUMihyFWQ/WDBbw7zmFVfxShkbzz4Dl
flZZPO3ok5h0Jw/zX358CkYpofSmRALwiFSbLtNjZ8o3LPUI7Pt0nTjqrjccmim9
SxxUWK9ERWi1i9nXDyb3UuxX16DWHbZbk8mr2/nPIlMl5SOFGeKZEMbHC6aX00pc
TuFZk188n9xTcsnAmzxIpPUdqg8q/s8wArihKI6fuFESBJ0qQWopRu+22G1Isy2l
2/ipfOtjeQNoGIjxlLXRNXaAZpc83AaXNSlIbCeHhucPum9D23dNMBLRwQ3nr1kR
pTLU7a8S38DqOpNs/yQee9U7vH3eRnVI1G1/jEbg7GKniVCvs2MTlHvy9lUV/nJ7
xH+LDRAUHR08/Lt85se0cu2tGqS9CBUl12de7uA0yhFJSFBdFYp8LRMy5mR+oeGj
fDLLEb6wD3xYvPNW/YVS/pXY9KV972xqmmnimKXeAuQfEYJaUroRR56926Jc6j3t
rNJgkOPcC+JBDI1W0LDZMtYzxf8pkbDw0IUS/XbH1+S4x06bSy+cFC+2Rl3kzUXv
7l0+L72dwxUS5tiJ4g==
=a+Wu
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function

[Marc]

On 01.06.23 18:16, G. P. B. wrote:

Hello internals,

The vote for the Define proper semantics for range() function RFC is now
open and will last for two weeks until the 15th of June 2023:

https://wiki.php.net/rfc/proper-range-semantics

Best regards,

George P. Banyard


Hi George,

sorry for speaking up so late but I think the following change is a 
mistake and unexpected:


> Calls to range() that have integer boundaries but a float step that 
is compatible as an integer will now return an array of integers instead 
of an array of floats:


var_dump( range(1, 5, 2.0) );
/* New Behaviour */
array(3) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(5)
}
/* Current Behaviour */
array(3) {
  [0]=>
  float(1)
  [1]=>
  float(3)
  [2]=>
  float(5)
}

The problem I see with this is that the return type changes from float 
to int "magically" based on the value of the step.

range(1, 5, 2.0) // list range(1, 5, 2.1) // list

In my opinion, no matter, if start, end or step is a float the result 
should be a list.


Thanks,

Marc

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