Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Mike Schinkel]

> On Jul 2, 2021, at 12:30 AM, Hossein Baghayi  
> wrote:
> 
> Hello,
> 
> On Sun, 27 Jun 2021 at 19:09, Ralph Schindler 
> wrote:
> 
>> 
>> This proposes a method for a publisher/framework/producer (the caller of
>> the callback) to document all the parameters that are available as named
>> parameters, and subscribers/consumers (creator of the callback) could
>> subscribe to what they need by name.
>> 
> 
> Wouldn't it rather be nice if we had more detailed callable types instead?
> I mean instead of simply defining a parameter type as `callable` we could
> specifically define what the callable expects.
> 
> Something like this:
> ```
> function bar ((int, string):bool $callback) {...}
> ```
> 
> A more generic approach that could be more descriptive, maybe.
> 
> I have no clue if this was already discussed in other threads or not. And
> whether it is feasible to implement.


From 2015 which failed (not sure why): 

https://wiki.php.net/rfc/callable-types

But I believe that would be better to be part of a broader ability to define 
our own types, e.g.

type function(int, string):bool IntStrFunc;
function bar (intStrFunc $callback) {...}

I think a few have mentioned user-defined types in the recent past but I am not 
aware of it being a current RFC for it. 

-Mike

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Hossein Baghayi]

Hello,

On Sun, 27 Jun 2021 at 19:09, Ralph Schindler 
wrote:

>
> This proposes a method for a publisher/framework/producer (the caller of
> the callback) to document all the parameters that are available as named
> parameters, and subscribers/consumers (creator of the callback) could
> subscribe to what they need by name.
>

Wouldn't it rather be nice if we had more detailed callable types instead?
I mean instead of simply defining a parameter type as `callable` we could
specifically define what the callable expects.

Something like this:
```
function bar ((int, string):bool $callback) {...}
```

A more generic approach that could be more descriptive, maybe.

I have no clue if this was already discussed in other threads or not. And
whether it is feasible to implement.

Regards,

Re: [PHP-DEV] Re: [Vote] Partial Function Application

[Olle Härstedt]

2021-07-01 17:12 GMT+02:00, Larry Garfield :
> On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote:
>> Hi folks.  The vote for the Partial Function Application RFC is now
>> open, and will run until 30 June.
>>
>> https://wiki.php.net/rfc/partial_function_application
>>
>> Of particular note, a few people had asked about using ...? instead of
>> ... for the variadic placeholder.  In the end we decided not to explore
>> that, as Nikita explained off-list it was actually more confusing, not
>> less, as it would suggest "placeholder for a variadic" rather than "a
>> placeholder that is variadic."  Otherwise, it's just more typing.  The
>> syntax choices section of the RFC has been updated accordingly.
>
>
> The vote has now closed.  The final result is:
>
> Yes; 29
> No: 20
> Percentage: 59.1%
>
> It has not passed.  Thank you everyone for your involvement.
>
> I'd like to bring this RFC back in the future in some form if either a less
> complex implementation or a stronger use case to justify the implementation
> can be found.  That would be a topic for a different thread at a different
> time.
>
> --Larry Garfield

Hi,

My personal impression is that the feedback loop between RFC authors
and voters seems a bit vague. Should the no-vote be split into "Yes,
but not like this", and "No, never"? Or maybe add a reason for the
no-vote? Like, too complex implementation, or weak use-case. I don't
know. Guessing should be reduced to a minimum, as should be wasted
effort.

I also believe the structure of the RFC itself could be more
disciplined, and collect pros and cons more clearly. Not this
particular RFC, but in general. I assume there's a scaffold being
used?

Olle

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

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Ralph Schindler]

If you want to ignore arguments in excess, your function may have a rest 
parameter collecting them. The following will run without error:

```php
function foo($c, $a, ...$unused) {
 var_dump($a, $c);
}

$args = [
 'a' => 'the a value'
   , 'b' => 'the b value'
   , 'c' => 'the c value'
];

foo(...$args);
```


This seems like a fairly clean alternative syntax with the only downside 
is an unused variable.


Thanks for the idea!

-ralph

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

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Ralph Schindler]

What I don't understand is what the issue with that is?

You can already build up a named array and splat it into a function call to 
pass by name.  It's a really neat trick.  It doesn't need a dedicated function.

About a month ago, I went through all of TYPO3 and removed all remaining 
call_user_func_array() calls in favor of just $function(...$args), because it 
does the same thing and is faster, and easier to read.  Named arguments already 
work exactly that way, too.

I don't see an advantage to adding a function that does what you can already do 
with less syntax:

$args['foo'] = 5;
$args['beep'] = get_value_from_db();
$args['narf'] = 'poink';

$callable(...$args);

That works today in 8.0.  We're good.


The proposal focuses on the onus put on the author of the 
closure/function, not the caller.


If your $callable is only interested in $foo enforced as an int and 
$narf enforced as a string, what does the signature and body of the 
subscribing $callable look like in this case?


I am proposing that if a system is providing all of this for any 
registered callables:


  $args['foo'] = 5;
  $args['beep'] = get_value_from_db();
  $args['narf'] = 'poink';
  $args['boop'] = $boopObject;
  $args['isNoomable'] = false;

But are only interested in value for 'foo' and 'narf', they can still 
get type hinting/checking/enforcement and the benefits of named mapping.



Let's assume the following which has a little bit of context:

  // developer/consumer code
  $library = (new SomeLibrary)
  $library->registerCallback(function ($foo, $narf) {});
  $library->call();

  // some 3rd party library with a callback system in place
  class SomeLibrary {
public function registerCallback(callable $callback) {
  $this->callback = $callback;
}
public function call() {
  if (!$this->callback) {
return;
  }

  $args = [];
  $args['foo'] = 5;
  $args['beep'] = 'value from db';
  $args['narf'] = 'poink';
  $args['boop'] = new StdClass;
  $args['isNoomable'] = false;

  ($this->callback)(...$args);
}
  }


This will fail with message:

  PHP Fatal error:  Uncaught Error: Unknown named parameter $beep in ...


Currently, the consumer/developer would have to write:

  $library->registerCallback(function (...$args) {
$foo = $args['foo'];
$narf = $args['narf'];
// ...
  });

  // or
   $library->registerCallback(function ($foo, $beep, $narf, $boop, 
$isNoomable) {

// do something with foo or narf
  });


Additionally, the library/framework is now precluded from adding new 
parameters since any consuming callables would also have to introduce 
these new parameters as it could be considered a BC break.


The more I think about it though, the more sensible this would be as it 
allows the callback provider to opt into named parameter mapping 
destructuring:



  $library->registerCallback(function (...[string $foo, string $narf]) {
// do something with $foo and $narf
  });


-ralph

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

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Claude Pache]

> Le 27 juin 2021 à 16:39, Ralph Schindler  a écrit :
> 
> The short proposal:
> 
> 
> Make a variation of this work (notice parameter order and 'b' is goes unused):
> 
>call_user_func_map(
>  fn ($c, $a) => var_dump($a, $c),
>  [
>'a' => 'the a value',
>'b' => 'the b value',
>'c' => 'the c value'
>  ]
>);
> 
>// string(11) "the a value"
>// string(11) "the c value"
> 
> 

Hi,

If you want to ignore arguments in excess, your function may have a rest 
parameter collecting them. The following will run without error:

```php
function foo($c, $a, ...$unused) {
var_dump($a, $c);
}

$args = [
'a' => 'the a value'
  , 'b' => 'the b value'
  , 'c' => 'the c value'
];

foo(...$args);
```

—Claude

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

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

[Marco Pivetta]

On Thu, Jul 1, 2021 at 6:06 PM Deleu  wrote:

> I honestly don't understand not wanting this just because of lack of
> cloning.
>

Agreed: improvements on cloning ergonomics can come later.

Also, the problem goes away the smaller your state becomes: this may
encourage some design towards more granular data-structures.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[Pierre]

Le 01/07/2021 à 17:25, Larry Garfield a écrit :

The most famous use case right now for with-er objects is PSR-7, which is where 
the naming convention comes from.  I cannot say how widely used it is outside 
of FIG-inspired value objects, but I am pretty sure it is used.
As long as you implement the with-ers manually, you don't need "clone 
with", you can create a new instance the old way (i.e. using the object 
constructor). Once there will be a "clone with" like feature, PSR's will 
be able to evolve, but right now they'll work as they are, and it's fine.

The key point is that you rarely need to clone service objects; value objects, 
however, you have to clone if you want to mutate.  Look at any PSR-7 pipleline.  
By design, it calls $request->withBlah($newBlah) a lot, and returns a new 
object.  That's the model that we want to support, and make *easier* to do, but 
the readonly flag makes *harder* to do than the status quo today.  (See my 
previous post on the subject in the last thread.)


That's the whole point of readonly properties, not to mutate. If you 
want readonly mutable properties, don't write the readonly keyword. Any 
attempt in mutating something that was explicitly closed sounds like 
you're doing something really wrong.


I mean by that that not all objects are services, value objects are 
values, they're not meant to mutate. If you need a different value, you 
use the object constructor. The right way in my opinion for PSR-7 
pipeline is to stick with the with-ers, because it makes it explicit, by 
contract, of what you are attempting to achieve in your middlewares, and 
yet still work using an interface and not an instance: this model is 
very flexible and highly extensible. And yes PSR-7 doesn't fit with 
readonly properties, but that's not a problem, having readonly 
properties doesn't mean you actually have to use them everywhere.



There are use cases for readonly that don't require cloning.  For those, it's 
useful.  I personally think asymmetric visibility would render readonly 
unnecessary and redundant, but Nikita disagrees, and he's the one writing the 
code so... :-)


Yeah, I very much like asymmetric visibility as well. But readonly and 
asymmetric visibility are not incompatible. They both answer to 
different needs, some of those use cases probably intersect, but 
readonly properties have the nice advantage of allowing you to write 
pure immutable objects with a very simple syntax, and I love that, 
there's much code I wrote and do maintain that'll fit perfectly with that.


Regards,

--

Pierre

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

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

[Deleu]

On Thu, Jul 1, 2021 at 5:25 PM Larry Garfield 
wrote:

> On Thu, Jul 1, 2021, at 9:49 AM, Pierre wrote:
> > Le 01/07/2021 à 16:38, Nicolas Grekas a écrit :
> > > Hi NIkita,
> > >
> > > I voted against the proposal because it doesn't work with cloning at
> all.
> > >
> > > Cloning is a critical feature of stateful objects, and we should solve
> it
> > > the same version that introduces readonly IMHO.
> > >
> > > If we figure out that we can't agree on a sensible improved behavior
> for
> > > cloning, we're going to be in a dead-end with readonly.
> > >
> > I respectfully disagree.
> >
> > Having readonly properties and immutable objects is a must have, but
> > changing property of an object while cloning, not so much. There's many
> > case where readonly properties will be valuable where you never need to
> > clone your objects. Actually, cloning objects is not something you do
> > every day.
> >
> > Please note that I agree with you that advanced / flexible clone
> > semantics would be a nice to have, but I don't see the lack of it
> > blocking for readonly properties.
> >
> > I personally don't have any real use case where I couldn't implement
> > withers on my objects doing the same than dedicated advanced clone
> > semantics. Could you please provide some real world examples ? People
> > could change their minds if they could see why it's so blocking for you.
> >
> > Regards,
>
> The most famous use case right now for with-er objects is PSR-7, which is
> where the naming convention comes from.  I cannot say how widely used it is
> outside of FIG-inspired value objects, but I am pretty sure it is used.
>
> The key point is that you rarely need to clone service objects; value
> objects, however, you have to clone if you want to mutate.  Look at any
> PSR-7 pipleline.  By design, it calls $request->withBlah($newBlah) a lot,
> and returns a new object.  That's the model that we want to support, and
> make *easier* to do, but the readonly flag makes *harder* to do than the
> status quo today.  (See my previous post on the subject in the last thread.)
>
> There are use cases for readonly that don't require cloning.  For those,
> it's useful.  I personally think asymmetric visibility would render
> readonly unnecessary and redundant, but Nikita disagrees, and he's the one
> writing the code so... :-)
>
> The best case scenario is by 8.2 we end up with asymmetric visibility and
> clone-with, and combined with readonly we get a huge array of options for
> how to lock down value objects and still make them evolvable.  The worst
> case scenario is we find that readonly cannot be extended to support
> clone-with for some hand-wavy engine reasons, at which point it becomes
> largely vestigial in favor of asymmetric visibility and clone-with.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I'd say don't use readonly on PSR-7. I have so many use cases for readonly
property and no use case for cloning. readonly syntax is far superior than
asymmetric visibility and will be almost as good as Constructor Promotion
Property. I would even go as far to say that I don't need anything more
than just readonly as-is. I think the bigger picture here is how many use
cases are there that would vastly benefit from this Vs how many use cases
could potentially benefit from it but won't because of lack of cloning
support. Of course everyone's opinion will be shaped by the universe they
live in and in mine this RFC covers everything I need with no drawbacks and
I honestly don't understand not wanting this just because of lack of
cloning.


-- 
Marco Aurélio Deleu

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Larry Garfield]

On Thu, Jul 1, 2021, at 10:14 AM, Ralph Schindler wrote:
> (Jump to bottom for alternative suggestion that achieves same goals)
> 
> 
> 
> > Just to make sure I got this right: call_user_func_map() is the same as 
> > call_user_func_array(), but a) only accepts named params
> 
> Yes, only accepts named parameters (associative array),
> 
> > and b) silently ignores unknown named params?
> I would characterize this as "explicitly doesn't pass unrequested 
> parameters"
> 
> > I'm not really convinced by your use-case here. This seems like a rather 
> > odd way to design an API, which goes against commonplace assumptions. If 
> 
> I didn't invest a lot of thought in the use case to make the argument, ha.
> 
> That said, I disagree with "odd way to design an API" sentiment...
> 
> This is a common idiom in a few different places found inside 
> frameworks. Laravel and Symfony both do named argument mapping when 
> dispatching controller actions. Additionally, both containers do a 
> significant amount of work with Reflection to map named arguments with 
> potential parameters.
> 
> I am not discrediting the fact that they don't also do more complex 
> stuff, but I think this supports the argument that this method of 
> parameters mapping does not go against commonplace assumptions.
> 
> Eg:
> https://github.com/symfony/http-kernel/blob/5.3/HttpKernel.php#L149-L157
> https://github.com/symfony/dependency-injection/search?q=reflectionMethod
> https://github.com/laravel/framework/blob/8.x/src/Illuminate/Container/Container.php#L649

What I don't understand is what the issue with that is?

You can already build up a named array and splat it into a function call to 
pass by name.  It's a really neat trick.  It doesn't need a dedicated function.

About a month ago, I went through all of TYPO3 and removed all remaining 
call_user_func_array() calls in favor of just $function(...$args), because it 
does the same thing and is faster, and easier to read.  Named arguments already 
work exactly that way, too.

I don't see an advantage to adding a function that does what you can already do 
with less syntax:

$args['foo'] = 5;
$args['beep'] = get_value_from_db();
$args['narf'] = 'poink';

$callable(...$args);

That works today in 8.0.  We're good.

--Larry Garfield

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

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

[Larry Garfield]

On Thu, Jul 1, 2021, at 9:49 AM, Pierre wrote:
> Le 01/07/2021 à 16:38, Nicolas Grekas a écrit :
> > Hi NIkita,
> >
> > I voted against the proposal because it doesn't work with cloning at all.
> >
> > Cloning is a critical feature of stateful objects, and we should solve it
> > the same version that introduces readonly IMHO.
> >
> > If we figure out that we can't agree on a sensible improved behavior for
> > cloning, we're going to be in a dead-end with readonly.
> >
> I respectfully disagree.
> 
> Having readonly properties and immutable objects is a must have, but 
> changing property of an object while cloning, not so much. There's many 
> case where readonly properties will be valuable where you never need to 
> clone your objects. Actually, cloning objects is not something you do 
> every day.
> 
> Please note that I agree with you that advanced / flexible clone 
> semantics would be a nice to have, but I don't see the lack of it 
> blocking for readonly properties.
> 
> I personally don't have any real use case where I couldn't implement 
> withers on my objects doing the same than dedicated advanced clone 
> semantics. Could you please provide some real world examples ? People 
> could change their minds if they could see why it's so blocking for you.
> 
> Regards,

The most famous use case right now for with-er objects is PSR-7, which is where 
the naming convention comes from.  I cannot say how widely used it is outside 
of FIG-inspired value objects, but I am pretty sure it is used.

The key point is that you rarely need to clone service objects; value objects, 
however, you have to clone if you want to mutate.  Look at any PSR-7 pipleline. 
 By design, it calls $request->withBlah($newBlah) a lot, and returns a new 
object.  That's the model that we want to support, and make *easier* to do, but 
the readonly flag makes *harder* to do than the status quo today.  (See my 
previous post on the subject in the last thread.)

There are use cases for readonly that don't require cloning.  For those, it's 
useful.  I personally think asymmetric visibility would render readonly 
unnecessary and redundant, but Nikita disagrees, and he's the one writing the 
code so... :-)

The best case scenario is by 8.2 we end up with asymmetric visibility and 
clone-with, and combined with readonly we get a huge array of options for how 
to lock down value objects and still make them evolvable.  The worst case 
scenario is we find that readonly cannot be extended to support clone-with for 
some hand-wavy engine reasons, at which point it becomes largely vestigial in 
favor of asymmetric visibility and clone-with.

--Larry Garfield

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

[PHP-DEV] PHP 7.4.21 Released!

[Derick Rethans]

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

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

For source downloads of PHP 7.4.21 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.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.



php-7.4.21.tar.gz
SHA256 hash: 4b9623accbe4b8923a801212f371f784069535009185e7bf7e4dec66bbea61db
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmDbOeQACgkQkQ3rRvU+
oxLhuhAA13eQvKLaox8U4r3ZbZfOX0UbfWsLhfOBZ3sx+gHgeyOF/Ix4F1SJJ4nW
WyUDrzHAi+zj2geftOCd8jNOLuFHAtq6YABnsRURMgXLMJ4ATgk9Vokcizx6c5Fi
l6ZLWbrfOVC+jo0EExqYAOVtwpkoRuMYrbnkGgvlwIYNrZA4v/YWAzUEALIszWIL
WLAxpe3jqWbvGaRWeCDLEDsv1IUVxYhpv7Q+D8DltfHTgfO0O0yuekRuQFfElqXe
gLiSCewEgjBf1A5mz00HhU0W602GKs6qwlMOz/0a4DSimCQrBa25k7pTtVM4yoRw
IY3zmxd9go1mdeN08kcehbLAr0LK7YWGjyhRtzkGFazJNfnZGdhD/AjJTkKVG/Ee
yUo3CEdp3DeKNFvgHMBDDcaoAy7vpqFIY7/bLO6JS1imB/Hz+btnAhatiaVL2WhQ
4Y852ILYqUiQjzhnJ5/aC7tpPl2+LxA8RQa6KTb9Kek9xAqNWsfzNwXKlxbilD3N
1XBkONc4fELyCwAjJBn2WHFlkiaudg9hQj3AGBpMkAsfKg7uMxpl24j60NXKcdic
OWobhH0WeqJSQMDvSa3tqyySi8/DffQy0KttgbhkIoPXzyyzPWWxIL20cVBVoap6
YtjNPuMY2IU3Tt/G4aUtHABUzVsCqbRWjMdOatZTDepqM+JNQls=
=JmZz
-END PGP SIGNATURE-

php-7.4.21.tar.bz2
SHA256 hash: 36ec6102e757e2c2b7742057a700bbff77c76fa0ccbe9c860398c3d24e32822a
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmDbOegACgkQkQ3rRvU+
oxLO9Q/9Eo2OUUioKniDZQVl5OsvNHPjbrmYYZ1CDki1mBJLZlTJuJNOqvdD3P23
toj356J/gOwr/LNprDpoHIy+jhFJCNOsBSbI0QlCE29KSGokgkHYg8LUS8QWvNbL
37wxQNXY0hW6w0gDJxkWKsfDq5LGI/XI3GgnggMLOW6bahalaxSrC5UFOQsu99z9
bDUvgNDQG6ykVmpfyEHNAbHDjNEIZOG+2vJSYBkkbgvdZMXuWCEAkvIJH0QsYSKu
vyvXu38U01WL1f8WAtnhFS16l6uGv4JZF4O0yroGEsa4pRP3NXKH7Cy6Qdnlf/Mk
dgQCRHpeh4MHJUCBZkDmXlLSWRmfAQA4b/JS5mvQibsWf9EJyPQfxpXDqnxPwE0m
gFHb9/RTF1YW8wKoHGbqdeLmMeNbupOuDujzIUa5qS53ethjB5jkT6JY+K/mvE3U
SPkB2vgaFpLzheByX9qCWlppB6eLBuv3TZ7xWIjfNyb2Cf9mKc9p04CtY4jWTTg3
fthaZJjjd7muFMPidb5T7GPhZp3TYSqV2jP/v/YpiU1aAfXQKJ7jwkcDpXKd873z
a/HXAq/4dVcmAkecQ/B9PuLLR/ZmzUq0FkYx680GWHUg1oWScfrh6ZRkYHE79URE
Hk5ouc/NZL9i87f9x83Kh4uyv9B8DBjbojtaOoqsMwTaGP0eUM4=
=C71t
-END PGP SIGNATURE-

php-7.4.21.tar.xz
SHA256 hash: cf43384a7806241bc2ff22022619baa4abb9710f12ec1656d0173de992e32a90
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmDbOegACgkQkQ3rRvU+
oxLXLw/+J/KEaPjcVSHweueJKWjzUJ0bMdUV+AfkPRmSmsIwYZxklhTxVjRvPgd2
jka0gkA4Nm0mUel/fj1xlt64DGiEfELALwS5g63OGlqA2pn9ZWQCt6l+SzROreT0
pIkO5fcKYWCd4rPQsV2I6Fq0IGKGHgkLyjUI/n9NsTHVkYkFV7YzIN5IgL02od2c
g2gse/awaCoZ+uMXROYRwj0QnX7uds/EvpPlgWNlGqctCWmENisYDobEaDnPi6TJ
7WWBoK0kk3APH0Fi+51bzwZHY3L0+OQ5hZbXtY+vAro2qg/qWw0URSJ2cN6eBBh+
iNU2Ap7nObjrhI/pF++VAj7w5khqM/JL7Pag/AttCDReor/Cgu5zOF+bS+N+XHcv
KA6Z4/I49/AaUjT+FIwQ3U15TE4dwoEC3bysp0BHm8cy4br2aq+XCxURgQAH2dpD
sxjWkVc6FZyZ+MqV1b1z3Wms3vCT1uWipojwniOujC9FjFFbP+cZirw4ZDD76RAW
FI6+iuftxdYhEDjwtmUUpncybHoITptFwBD39ciTORlnvvuk5WX/owZ6nwY+9BoF
OmEDriPKnKNoD4gogFlgSZKdKuVD9tMv6C+B9H9MO6Vswwdfawk2o13JZhEcoE0S
gw/K0Sn/Mh/ouSmOVm9+WWxocfw+WIzLYs7DD0Alu3zuOugshKA=
=ATAc
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

[Ralph Schindler]

(Jump to bottom for alternative suggestion that achieves same goals)



Just to make sure I got this right: call_user_func_map() is the same as 
call_user_func_array(), but a) only accepts named params


Yes, only accepts named parameters (associative array),


and b) silently ignores unknown named params?
I would characterize this as "explicitly doesn't pass unrequested 
parameters"


I'm not really convinced by your use-case here. This seems like a rather 
odd way to design an API, which goes against commonplace assumptions. If 


I didn't invest a lot of thought in the use case to make the argument, ha.

That said, I disagree with "odd way to design an API" sentiment...

This is a common idiom in a few different places found inside 
frameworks. Laravel and Symfony both do named argument mapping when 
dispatching controller actions. Additionally, both containers do a 
significant amount of work with Reflection to map named arguments with 
potential parameters.


I am not discrediting the fact that they don't also do more complex 
stuff, but I think this supports the argument that this method of 
parameters mapping does not go against commonplace assumptions.


Eg:
https://github.com/symfony/http-kernel/blob/5.3/HttpKernel.php#L149-L157
https://github.com/symfony/dependency-injection/search?q=reflectionMethod
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Container/Container.php#L649


you pass a closure somewhere, the general expectation is that the 
parameter names you use are irrelevant and only the order matters. This 
creates a very unusual API contract, and while I can't prevent you from 
doing that, I'm pretty sure this is not something we want to endorse 
with additional library support.


(The same question for named parameters in general is answered by 
https://wiki.php.net/rfc/named_params#what_are_the_benefits_of_named_arguments 
 
-- notably none of the arguments made there are relevant in this 
context, the only benefit I see is saving a few keystrokes.)


Named mapping is arguably better than forced ordered mapping for all the 
reasons laid out in the above link.  One of the primary benefits being 
you get type checking and better language supported analysis from 
tooling (like your IDE knowing the type of the parameter).


This is the effective way of accomplishing what you suggested today, you 
can skip parameters here but get no type checking:


  $f = function ($params) {
[$foo, $baz] = null;
extract($params, EXTR_IF_EXISTS);

var_dump($foo, $baz); //
  };

  $f(['foo' => 'a', 'bar' => 'b', 'baz' => 'c']);
  // string(1) "a"
  // string(1) "c"



What's wrong with good old fn($params) => $params['a'] + $params['b']? 



...Maybe nothing, perhaps if instead of adding parameters or new 
functions to call_user_func_* (language construct functions) we instead 
can add some type checking and destructuring to it ;)



# Alternative Suggestion

An alternative suggestion would be to follow Javascript's lead to 
accomplish something similar and allow parameter destructuring, but in a 
more PHP way:


  $f = function (...[string $foo, string $baz]) {
var_dump($foo, $baz);
  };

  $f(['foo' => 'a', 'bar' => 'b', 'baz' => 'c']);
  // string(1) "a"
  // string(1) "c"


-ralph

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

[PHP-DEV] Re: [Vote] Partial Function Application

[Larry Garfield]

On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote:
> Hi folks.  The vote for the Partial Function Application RFC is now 
> open, and will run until 30 June.
> 
> https://wiki.php.net/rfc/partial_function_application
> 
> Of particular note, a few people had asked about using ...? instead of 
> ... for the variadic placeholder.  In the end we decided not to explore 
> that, as Nikita explained off-list it was actually more confusing, not 
> less, as it would suggest "placeholder for a variadic" rather than "a 
> placeholder that is variadic."  Otherwise, it's just more typing.  The 
> syntax choices section of the RFC has been updated accordingly.


The vote has now closed.  The final result is:

Yes; 29
No: 20
Percentage: 59.1%

It has not passed.  Thank you everyone for your involvement.

I'd like to bring this RFC back in the future in some form if either a less 
complex implementation or a stronger use case to justify the implementation can 
be found.  That would be a topic for a different thread at a different time.

--Larry Garfield

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

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

[Pierre]

Le 01/07/2021 à 16:38, Nicolas Grekas a écrit :

Hi NIkita,

I voted against the proposal because it doesn't work with cloning at all.

Cloning is a critical feature of stateful objects, and we should solve it
the same version that introduces readonly IMHO.

If we figure out that we can't agree on a sensible improved behavior for
cloning, we're going to be in a dead-end with readonly.


I respectfully disagree.

Having readonly properties and immutable objects is a must have, but 
changing property of an object while cloning, not so much. There's many 
case where readonly properties will be valuable where you never need to 
clone your objects. Actually, cloning objects is not something you do 
every day.


Please note that I agree with you that advanced / flexible clone 
semantics would be a nice to have, but I don't see the lack of it 
blocking for readonly properties.


I personally don't have any real use case where I couldn't implement 
withers on my objects doing the same than dedicated advanced clone 
semantics. Could you please provide some real world examples ? People 
could change their minds if they could see why it's so blocking for you.


Regards,

--

Pierre

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

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

[Nicolas Grekas]

Le jeu. 1 juil. 2021 à 12:23, Nikita Popov  a écrit :

> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2.
> The vote closes 2021-07-15.
>
> See https://externals.io/message/114729 for the discussion thread on this
> proposal. I think a decent tl;dr is that readonly properties as proposed do
> not play well with clone-based withers, so some people believe we should
> either improve cloning first, or introduce asymmetric property visibility
> instead, which does not suffer from this issue.
>

Hi NIkita,

I voted against the proposal because it doesn't work with cloning at all.

Cloning is a critical feature of stateful objects, and we should solve it
the same version that introduces readonly IMHO.

If we figure out that we can't agree on a sensible improved behavior for
cloning, we're going to be in a dead-end with readonly.

I think we are not in a hurry and that we should wait for the RFC that
improves cloning to add readonly.

In another thread, you write:

 It's okay to vote against this if cloning is a deal breaker. In that case
> I'll probably either work on cloning before re-proposing this, or pivot to
> asymmetric visibility -- it's not my first preference, but it may be the
> more pragmatic choice. Cloning is definitely the weak point of this
> proposal.
>

I think this is a strong enough weak point to warrant postponing the
decision. Also, this very statement about asymmetric visibility being more
pragmatic is a string hint that we need time to explore it at the same time
IMHO.

Cheers,
Nicolas

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

[Pierre Joye]

On Thu, Jul 1, 2021, 9:14 PM Christoph M. Becker  wrote:

> On 01.07.2021 at 14:15, Pierre Joye wrote:
>
> > Hi Nikita,
> >
> > On Wed, Jun 30, 2021, 4:32 PM Nikita Popov  wrote:
> >
> >> Hi internals,
> >>
> >> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1.
> The
> >> vote closes on 2021-07-14.
> >>
> >> This RFC is a collection of various deprecation suggestions from
> different
> >> people. Each deprecation is voted separately, and should be considered
> on
> >> its own merit.
> >>
> >> Most deprecations should be uncontroversial, but there are some more
> >> contentious ones as well: See https://externals.io/message/113657 for
> >> additional discussion.
> >
> > I hope the num_points do not pass. However if it does, I would like to
> > still reconsider it for the reasons I mentioned in the discussion:
> support
> > nightmare
> >
> >  Any image will be broken if a server is not configured smoothly for
> prod.
> > Unlike another script, the depreciation is not visible directly in the
> > page. Given the amount of usages of these functions out there, I really
> ask
> > to reconsider this one. Too much possible hassles for no real gain.
>
> In my opinion, *not* having a signature like
>
> function imagepolygon(
> GdImage $image,
> array $points,
> int $num_points_or_color,
> ?int $color = null
> ): bool {}
>
> and the respective implementation mess, is a gain; not a huge gain, but
> still a real gain to me.
>
> And image generation code which relies on display_errors to catch errors
> is already broken.  By your argument, we could not even introduce new
> warnings.
>
> Anyhow, fixing the deprecated code would be trivial (the RFC shows an
> example), and can even be automated, and I consider it not unlikely that
> code which runs on PHP 8 has unit-tests and/or static analysis what may
> catch this issue early.


The codes which will do this are not the ones I am worrying about. This is
not some function never used before but anyone out there. Or something that
causes pains to the engine or prevents major features to happen. This
function has to be replaced, not made incompatible.

best
Pierre

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

[Christoph M. Becker]

On 01.07.2021 at 14:15, Pierre Joye wrote:

> Hi Nikita,
>
> On Wed, Jun 30, 2021, 4:32 PM Nikita Popov  wrote:
>
>> Hi internals,
>>
>> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The
>> vote closes on 2021-07-14.
>>
>> This RFC is a collection of various deprecation suggestions from different
>> people. Each deprecation is voted separately, and should be considered on
>> its own merit.
>>
>> Most deprecations should be uncontroversial, but there are some more
>> contentious ones as well: See https://externals.io/message/113657 for
>> additional discussion.
>
> I hope the num_points do not pass. However if it does, I would like to
> still reconsider it for the reasons I mentioned in the discussion: support
> nightmare
>
>  Any image will be broken if a server is not configured smoothly for prod.
> Unlike another script, the depreciation is not visible directly in the
> page. Given the amount of usages of these functions out there, I really ask
> to reconsider this one. Too much possible hassles for no real gain.

In my opinion, *not* having a signature like

function imagepolygon(
GdImage $image,
array $points,
int $num_points_or_color,
?int $color = null
): bool {}

and the respective implementation mess, is a gain; not a huge gain, but
still a real gain to me.

And image generation code which relies on display_errors to catch errors
is already broken.  By your argument, we could not even introduce new
warnings.

Anyhow, fixing the deprecated code would be trivial (the RFC shows an
example), and can even be automated, and I consider it not unlikely that
code which runs on PHP 8 has unit-tests and/or static analysis what may
catch this issue early.

Christoph

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Alexandru Pătrănescu]

On Thu, Jul 1, 2021 at 3:05 PM Hamza Ahmad 
wrote:

> Hi all,
>
> While I was reading through the discussion, I found a question related
> to the conflict of constant names and functions names. In other words,
> `strlen` can be both a constant name and a function name.
>

This was stated before but, basically, the idea is that the difference
between a constant and function or between the property and the method (or
class constant and static method) is done on the usage side, if a calling
syntax is encountered.
$a = strlen; // reading the constant
$a = strlen(); // calling the function
$a = $this->run; // reading the property
$a = $this->run(); // calling the method
$a = Clazz::operation; // reading the static property (or enum case)
$a = Clazz::operation(); // calling the static method

This way of identifying it is something embedded in the language and
probably not that easy to avoid.
This is why the syntax is similar to a method call, to properly identify
the callable without other new syntax.

Alex

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

[Pierre Joye]

Hi Nikita,

On Wed, Jun 30, 2021, 4:32 PM Nikita Popov  wrote:

> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The
> vote closes on 2021-07-14.
>
> This RFC is a collection of various deprecation suggestions from different
> people. Each deprecation is voted separately, and should be considered on
> its own merit.
>
> Most deprecations should be uncontroversial, but there are some more
> contentious ones as well: See https://externals.io/message/113657 for
> additional discussion.


I hope the num_points do not pass. However if it does, I would like to
still reconsider it for the reasons I mentioned in the discussion: support
nightmare

 Any image will be broken if a server is not configured smoothly for prod.
Unlike another script, the depreciation is not visible directly in the
page. Given the amount of usages of these functions out there, I really ask
to reconsider this one. Too much possible hassles for no real gain.


thanks.

Re: [PHP-DEV] [Vote] Partial Function Application

[Hamza Ahmad]

Hi all,

While I was reading through the discussion, I found a question related
to the conflict of constant names and functions names. In other words,
`strlen` can be both a constant name and a function name. Thus, in
pipe RFC, it can go confusing whether it is a constant or a function
name when called this way:
```
'abc'
|> strtoupper
|> md5(?, true)
|> bin2hex
|> base64_encode;
```

In Javascript alert and confirm are by default names. In reality, they
are methods of window object. When they are assigned to a new value,
they don't give a reference to the methods of window object.

When a function or a method name is referred without parenthesis,
JavaScript returns the function object. It is Useful because it does
not require quoting. For example, `window.setTimeout(alert, 1000);`.
A more popular example is `if (window.XMLHttpRequest)`.

Even I tested this, and it worked. I hated this behavior.
```
function ok(){};
console.log(typeof ok);
ok = 123;
console.log(typeof ok);
```

In PHP, all in-namespace symbols are first searched in the namespace.
If not found, they are looked in the global namespace. If still not
found, the error is thrown.

In the light of these two examples, I have these suggestions:
1. declare all function/method names respectively constants and
variables by default and make them modifiable. This functionality is
present in OOP; it is possible to redeclare constants and methods that
are non-final.
2. As you have removed the ability to declare a case-insensitive
constant, stop invocation of function names case-insensitively. Of
course, it requires an RFC.
3. Disallow declaration of constants and using the names of functions
static methods. Same applies to variables and non static methods of a
class. As a result, no one can declare `strlen` as a constant. If one
tries to make a method with a name of a property, it will also get an
error.

I don't know how many bc breaks these applications will bring. If they
are approved, I am sure it will not only solve the problem that gave
birth to this idea, but also it will prevent bad practices. For
example,
```
 wrote:
> 2021-06-30 19:10 GMT+02:00, Larry Garfield :
>> On Wed, Jun 30, 2021, at 8:59 AM, Olle Härstedt wrote:
>>
>>>  > I've been pondering if a completely different approach with a prefix
>>>  > symbol would be able to be less complex, and the simple answer is I
>>>  > have absolutely no idea.  But we are running low on symbols...
>>>
>>>  Ah, I found the technical details that Joe gave me (right after I hit
>>> send, of course).  Quoting Joe:
>>>
>>>  "the engine expects certain things to happen, and is designed and then
>>> optimized around those assumptions ... for example, a stream of INIT,
>>> SEND, DO_FCALL is not meant to be interrupted, the first fundamental
>>> change you have to make is making the engine aware that stream of INIT,
>>> SEND, + are not always followed by DO_FCALL "
>>>
>>>  So yes, it sounds like hooking into the function call process is where
>>> the complexity comes from.  Which suggests that an approach that works
>>> using a different syntax that desugars to a closure would avoid that
>>> issue, but then we need a syntax that wouldn't be ambiguous, and that's
>>> getting harder and harder to find.  (Nikita's first-class-callables RFC
>>> notes some of the issues with available symbols, and they're
>>> essentially the same for partials either way.)  And I've been told that
>>> creating closures in the AST compiler is Hard(tm)...
>>>
>>>  --Larry Garfield
>>>
>>>
>>> Wrapping stuff in lambdas is otherwise the obvious solution, no? Make
>>> `strlen(?)` evaluate to `fn ($x) => strlen($x)`. Does it depend on the
>>> level of look-ahead in the compiler why it's so hard? Didn't work much
>>> with scripting language internals.
>>>
>>> Olle
>>
>> The tricky part is that conversion has to happen entirely at runtime,
>> because we need the type information from the function being partialed,
>> and
>> at that point creating an actual closure is, apparently, rather hard.  It
>> cannot be done up at the AST level where it would be conceptually much
>> easier.
>>
>> We've been discussing this for the past several days in chat, and the
>> basic
>> conclusion is that the PHP engine does not offer any easy way to do this.
>> It's one hard-and-messy approach or another hard-and-messy approach.  So
>> far
>> no one has figured out a not hard-and-messy way to make it work,
>> regardless
>> of performance.
>>
>> --Larry Garfield
>
> Alright, alright. Guess I have to learn a bit more about the different
> passes inside the compiler. :) Thanks.
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

Re: [PHP-DEV] PHP 8.0.8 Released!

[Remi Collet]

Le 01/07/2021 à 13:35, Gabriel Caruso a écrit :

The PHP development team announces the immediate availability of PHP
8.0.8. This is a bugfix release.


Should read: This is a security and bugfix release


Remi

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

[PHP-DEV] PHP 8.0.8 Released!

[Gabriel Caruso]

The PHP development team announces the immediate availability of PHP
8.0.8. This is a bugfix release.

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

For source downloads of PHP 8.0.8 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:   <
https://gist.github.com/carusogabriel/b6833d26731a1f7c46daa35a492fd97a>

Many thanks to all the contributors and supporters!

Gabriel Caruso & Sara Golemon

php-8.0.8.tar.gz
SHA256 hash: 084a1e8020e86fb99b663d195fd9ac98a9f37dfcb9ecb5c159054cdb8f388945
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmDa0i4WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjzWXD/981cez0YaYfZXqNe48kZNJDbu2
XRBg/tdFbeT6i+MkK4l+B0rzK3QimQA+XaIS6rCoDWgrck7qh9HiDUSiLADcwQrT
n7VbuWJ9TakoSiHhMGBUxqkbfUtn/Efh+e9IHKG1ZlKGXEf0Jn+QJOnWZjuHwoJM
l0y1LKAz0ZAZwx/ldUctRC9ZMQFseQaBGH6F46mm4ThyCzoKKYpykdmNTmPnN67z
pPa6H9kYA0tcRtVQnLrqFOc9dcxKAR0gB4KeZZiiuRtAnKn2GLTLpHL1rODKEpsr
+yWOqM1o42YzBM3rM0AJF6OzwOtyZUjIJ7iy9WKVEDkxD7A09DDBX7UJWAAzimT1
tYYzjdMtmkZM3IDkHOKaFS48E/LPDfamKCBQXhJ+AsEixopWIOBPLXhAU/srJr7E
x44WrKNXGQhRCVc8pBM8gO1muxOwP0U+a0fZ8furKZ432dD+Tudbj0OS1/ygf89q
T9czfWnSv3ay+mlWxa8W9OdhcFkNfdwvJMHI1sdJDMYvlbvhpW4aeuKQEi9liU63
oOXGj841EhBREqENyQJkW22XUSyAlaaO3jDCXRXZBemEC42NTHVE9WVJjXDnCwXP
yoEK9L7V1am0aghTMVKcDICM7Th1HR/HuzOD2FX6kWjQfD2Z6sPIDWpiGRtEfojm
HAsIxSaEIVibksXSgg==
=7YrD
-END PGP SIGNATURE-

php-8.0.8.tar.bz2
SHA256 hash: 14bd77d71a98943e14b324da83e31b572781df583cda9650a184fae3214cd16f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmDa0i8WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj7t8EADidekJNDXD8Z0VRzCtwlVfPBQn
C9XJIhW/CjYQJVuNn1cwfJrJQk+Tc/52iWOEOn8zS1/Mz4Gcq3J/9CeOP7GcYEqS
P33LMOuXDyUM/Ta7HxYfvLInbCOiQbvQAKaH6LZBV/q/YXZQ8e/l1N9vXtG+YVde
SBKbs6k56D7JD3yfhRuooHMlfdx095FmnaD5jv+9/CybnJLfYptaY1wRF47eW7G7
D46k0DzzeT4iD1/ZG/FVlunYZS3Kh7rYYEK8sq++Wh/ONAmNl7f6AxuVXOp40ViF
JtHEBYAdzZBznVwDCUNWLSVWsDAHns8s5fieQPHXqr2tiNmJhpDY9eytkr8tKkHL
/t71RJI5RmcrgTPBl447RsWHQKVT2wSgUpgsCCdX+4MrDc16pasbngket7L1Oc5+
tzuDeJ89ODxAjYvRiJy0Cdlnwyt4A3B3k3P1r6AFimVkzQlCCHusXvv4J0b2MoXp
aC4wVgHz4h640UKgFlrWV9SoMFHAs8X05O7Kvy7ZYO721aHqq7JOcvVUExssrXQZ
QCngnIl6vEcAV52v7lJgZU9bAHezhj4m59ja7XjIzo3WgcmAKn/xN3pW4ELaottp
U8i5tDjPL+gqpBgZyDjHZjnJ4g3wvv0Urn1vid8Y4v9jXGOa1nnK6zKle+TL17L6
DbLZhzyqjs73t3TXUA==
=dBbp
-END PGP SIGNATURE-

php-8.0.8.tar.xz
SHA256 hash: dc1668d324232dec1d05175ec752dade92d29bb3004275118bc3f7fc7cbfbb1c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmDa0i8WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj/ivEACrc3z35bGH7z7s/mXCMnQS0lZF
1AlN3rRLBGAYYxsx1UDf5ML7aIQU8KU8bb2pv/lQnFxmbZ+jtRiRSJxvuK5t031l
umLfGw+XBTpgfi7c8L3v3S9KrdyJI9mn2s+Xl+tJ+K+Yf1z3vgTFidJ4wiHGWBVS
tHeAA7nh/Q639cBx17KGLwCqsEDYxbSQTsWdjp1w0yuyN+Ml0lWn+VroSfBBp43o
tL1vWCmzEExJcFM4y7H12j+EK0CHNsJSuByj/Jt+/oVxjOKirG9PXkbOHWs+UMpZ
fjuZE/YNvbLRdKSwQlkrlc/7vhD4iGgv1V8ak8Soq9lbBvPTTNFBnx/ZJVtwoVVz
Frw2w8DnjY8j5Be2c8CDy9weUYaBnB+5xNB54c5IN9Cq1W6USqs+uKpfHW3add74
hc1Ier2oZo+WM8M91QIauWp0IqDAQtPVOsJAujlarL4X11PXe9fklBoxKHBFGnjN
hwtQ+/7A+ECFMjQ7olmz+rLrtDnaMnSb2/2BiYDI1EcEccOrIZzq1OWw8NPWMLEx
EmEwrxodZTwXGZZgtshl5i+jtkIl1GCFfg1eW6GKCNYN1oylEa8VBM6gpPFkA6Ev
F5vvxag7S2J790PRZ17Dvnisg2vg2FSmtRtX/OGvKI2otZKtrcczBbgwa58fVezH
TQQdJTzg+YbOTT4sbA==
=do4l
-END PGP SIGNATURE-

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

[Hamza Ahmad]

Hi Nikita,

It is going to be the second contribution from you regarding OOP.
However, this proposal, as you have mentioned, has some issues with
cloning. What if you would have opened voting after fixing this?

Or, your mood is to get it passed and then fix it before final release of 8.1?

Thank you

Hamza Ahmad


On 7/1/21, Nikita Popov  wrote:
> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2.
> The vote closes 2021-07-15.
>
> See https://externals.io/message/114729 for the discussion thread on this
> proposal. I think a decent tl;dr is that readonly properties as proposed do
> not play well with clone-based withers, so some people believe we should
> either improve cloning first, or introduce asymmetric property visibility
> instead, which does not suffer from this issue.
>
> Regards,
> Nikita
>

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

[PHP-DEV] [VOTE] Readonly properties

[Nikita Popov]

Hi internals,

I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2.
The vote closes 2021-07-15.

See https://externals.io/message/114729 for the discussion thread on this
proposal. I think a decent tl;dr is that readonly properties as proposed do
not play well with clone-based withers, so some people believe we should
either improve cloning first, or introduce asymmetric property visibility
instead, which does not suffer from this issue.

Regards,
Nikita

[PHP-DEV] PHP 7.3.29 Released!

[Christoph M. Becker]

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

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

For source downloads of PHP 7.3.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: 
Downloads:
Windows downloads:
Changelog:

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.29.tar.bz2
SHA256 hash:
a83a2878140bd86935f0046bbfe92672c8ab688fbe4ccf9704add6b9605ee4d0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmDa6MsMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y21dkQAI+MY6I142AO1Ih78nJAIT2K8Kj8BZR9eNAQVqBJ
izfE4nNJYTeUeUB+FdibzbZ/OQr86FDhAowJqqT1ODjerK6s1UT3+Z7pHyE4uM0/
3wg/AO8FyyushLUw84AfIq2veRnL8axXoc5etU4l+i5LADsAiRUp3E8ABjea13Za
oiM0stksJX2KrNT1lQexp1igLGHLKUWaGBJFRsRuSBkF4xVMM80KBJ0MNI39eOC+
zR33FBpQAjYBorNkGBFVPzr1xZwOsSbnN1PHtK4X4Kd18PDR9x86n6yHjlNFRgpr
fopmIPIs0P3Yncy2Zwj/wd1zEx99d1By/lSxg0fACNbwfS5vGmFLzudmOwA06cHp
dCKrvJJqv/DiGVXwSpqlmuyQ01M2JG1K6O/QWCE9g1b+wtaBpISRjOuag6azFJUp
T4w2A9mlfO6uKeY8tmS2PPn6e4qCBI9tC9j3GtkazwrD9Uh8rV98repNz4oiSHuz
D+qVIMEYqt5vU9D3rvFeZ41+X7Hui9edLDxV4WAdJ4cPuMOaKqeQjfd2QMaShTNc
VB3uBEWkgSjUkYgFDXpK76w8dKyEzp6UCtGheLVVknZW7NIYVAgBx7neVjL/4Ndq
v0ghNshdG5eVK8Na1zvfRulyooqHHP8/qzWsuwC9wl1mzPbx3wJQPQoBrBrJPnEs
5cIU
=fnvW
-END PGP SIGNATURE-


php-7.3.29.tar.gz
SHA256 hash:
ba4de3955b0cbd33baee55a83568acc4347605e210a54b5654e4c1e09b544659
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmDa6MwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2GhsQAJifY1JI9NLMqGt9LyAC6+cSL7axabm7ZeXINhbC
/pjNF8Yw+htfOueWtBmIKQ1I2IGzDwoawhqPIZIIMDO9G+WxeiID5GikiW1lqAbl
62Fvb33h/PPHca8LJeVWkGXdtJPOOo+60W/Jk3K527YerKOfpUqRVZFBVdNuTa/L
UcYua9N5GLHW7dE8nPas1aeIBNpI+D7uBCvpwdA0WR2UiDyYyFGc3ho4Hj/tdIgO
gkqgicZIoDTGFAKkQ2qt3Zzyk8smAcjJmwc48KQAHKwKHHuU47MYQSp1eneDBazm
FaXD1aDeQU0BFT0XC/FAEEgFEPbnuaNRHT1yPs6zmRenq/56wzcgBpPBx0rQxuIB
NwpO9G9cqGvDSy1okXb9l9SGXg+/j9bQkO2N4tMQpbjOztGt65eROuOpkxzhM4o9
Ak9eqt8FtnkGZPcIWQLLdHa1jb44SFsl7/WX+t+YGzKpSvRiAYL4vddkAzvFA6K5
ZlB0kTvwaQ3j3wja+Ls5sSvBtf8wDGmh+sCFnbwj6OJHdEfU22NDgeJOQQSwEu9S
bQC+cz4YFLSyrnG3As+ee4PHyq9gGPJoSa3dsoGrLS7dH6AkePlM1wNMRPXeaEQU
TTn6kh8ItN/TRAQ1WHbLyEqjsTS76A9UkGNZzd/2i7cZ+mPvoed9kYduPbOprrWH
+huh
=Kb08
-END PGP SIGNATURE-


php-7.3.29.tar.xz
SHA256 hash:
7db2834511f3d86272dca3daee3f395a5a4afce359b8342aa6edad80e12eb4d0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmDa6MwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2SRMP/j+C835yaFYQnqzXmrOnlkFHKeuyOA2yWMDl6DeA
K+IIHvxq2LvRyGf3uYKkk5GWRq42TPKlV1tAMrzh3E+sgjLjQaGAyIbGx05Pl0Ke
fGb0Huoe8ag+L+VfgvtrZmQW6FqX60SaZbzqB5lZUEK+mqSIfbQjyi+7+xDvGSrj
urLj3QCf6VGrtqZOH1N0kVD9M7L0BQHgyj4Gat8AoiYcrurjWsElNJtvbipveVzP
uluAa1Sk5bEexOy1Y8B8YpzCJA/YXGdZgFbxzvVvI31Fy460OAc46+Y+gVKpm+Oa
vWMWy2H4+o4HZ9BisS99tilx8WzBvCAMnuLd/pqOte5Esv/gOzuDYmGSTqQ4NGck
+yOIPJlXWLm02PmyknY/71AyyG3DYYu0JjtvLj8q/m224l40VJJow151UnVpJKNB
S3ZsKDC8RvgpWl1yoNbM4GcYAWoMhmsQZR5YdgzcFKAx/obSDfQ0Kzeh4uzAnNU9
jCHej+cJ6GQ6MqBMh2U544DgQfpNzMD+QzoJ6eq9KvNCnjHj1EiNunOBZfh87snz
lfoM69eovNP+elQHce62jZp6i8TGr+8nQ67u5hgf1AQLyniloGSynLT/GJ+JBZLA
Xdz7RYGSAQscDVi1EUPCECXfnk5NIgBMVTQYeQjOafEfeb77tm3EuMfvayvwmBE5
g9qP
=Pxpg
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Olle Härstedt]

2021-06-30 19:10 GMT+02:00, Larry Garfield :
> On Wed, Jun 30, 2021, at 8:59 AM, Olle Härstedt wrote:
>
>>  > I've been pondering if a completely different approach with a prefix
>>  > symbol would be able to be less complex, and the simple answer is I
>>  > have absolutely no idea.  But we are running low on symbols...
>>
>>  Ah, I found the technical details that Joe gave me (right after I hit
>> send, of course).  Quoting Joe:
>>
>>  "the engine expects certain things to happen, and is designed and then
>> optimized around those assumptions ... for example, a stream of INIT,
>> SEND, DO_FCALL is not meant to be interrupted, the first fundamental
>> change you have to make is making the engine aware that stream of INIT,
>> SEND, + are not always followed by DO_FCALL "
>>
>>  So yes, it sounds like hooking into the function call process is where
>> the complexity comes from.  Which suggests that an approach that works
>> using a different syntax that desugars to a closure would avoid that
>> issue, but then we need a syntax that wouldn't be ambiguous, and that's
>> getting harder and harder to find.  (Nikita's first-class-callables RFC
>> notes some of the issues with available symbols, and they're
>> essentially the same for partials either way.)  And I've been told that
>> creating closures in the AST compiler is Hard(tm)...
>>
>>  --Larry Garfield
>>
>>
>> Wrapping stuff in lambdas is otherwise the obvious solution, no? Make
>> `strlen(?)` evaluate to `fn ($x) => strlen($x)`. Does it depend on the
>> level of look-ahead in the compiler why it's so hard? Didn't work much
>> with scripting language internals.
>>
>> Olle
>
> The tricky part is that conversion has to happen entirely at runtime,
> because we need the type information from the function being partialed, and
> at that point creating an actual closure is, apparently, rather hard.  It
> cannot be done up at the AST level where it would be conceptually much
> easier.
>
> We've been discussing this for the past several days in chat, and the basic
> conclusion is that the PHP engine does not offer any easy way to do this.
> It's one hard-and-messy approach or another hard-and-messy approach.  So far
> no one has figured out a not hard-and-messy way to make it work, regardless
> of performance.
>
> --Larry Garfield

Alright, alright. Guess I have to learn a bit more about the different
passes inside the compiler. :) Thanks.

Olle

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