Re: [PHP-DEV] [RFC] First-class callable syntax

[David Gebler]

On Thu, May 20, 2021 at 8:38 PM Larry Garfield 
wrote:

>
> There's been a lot of rapid iteration, experimentation, and rejection.
> The most recent alternatives are this one from Levi:
>
> https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd
>
> And this one from me:
>
> https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8
>
>
Intuitively, I think I prefer your algorithm as these are written up.
Levi's allows for named placeholders which I'm sure for some users is a big
draw. But I think what you're proposing is cleaner and will be better
understood. It resolves a lot of the concerns which came up in the PFA
thread, striking a reasonable balance between benefit and simplicity.

Either way suggests compatibility with Nikita's proposal, assuming use of
the spread operator as the implemented syntax. For this RFC in isolation,
though, it does loosely concern me as a user the proposed syntax looks more
like a function call. I won't bog anyone down arguing the syntax, it's a
minor detail for users to get used to in the grand scheme of things and I'd
definitely rather it was possible to build the more powerful PFA on top
than bin that off, or end up with a convoluted PHP providing competing ways
of doing the same thing.


> * Named arguments make things more complicated.  One of the questions is
> whether named placeholders should be supported or not.  And if they are,
> does that mean you can effectively reorder the arguments in the partial
> application, and what does that mean for usability.  It gets complicated
> and scope-creepy fast.
>

I do share the concern about named arguments and it's one of the reasons I
prefer your proposal. I think scaling back the scope a little bit is
exactly what's needed right now.


> While I agree Nikita's RFC here would be an improvement over 8.0, I don't
> think throwing in the towel on PFA yet is a good idea.  It's a much more
> robust and powerful approach that still gets us the "first class callable"
> syntax we all want (at least I assume we all do), and lots of additional
> power to boot.  I'd rather see us try to drive PFA home to completion.  If
> that proves impossible by early July, then this RFC would still get us
> something this cycle, as long as the syntax is still compatible with PFA.
>

I think this is very sensible, I can only really say I'd rather have
Nikita's proposal land in 8.1 and PFAs in 9.0 done right than have PFAs in
8.1 but in a way which is confusing, ambiguous or problematic for users, or
not covering reasonable expected use cases.

Re: [PHP-DEV] [RFC] First-class callable syntax

[Rowan Tommins]

On 20/05/2021 21:54, Kamil Tekiela wrote:

This would be less confusing than the (...) syntax IMHO. Of course this
still has the same ambiguity as Rowan points out. Is ::$objA->methA a
property or a method? We could solve this problem by specifying the syntax
to always refer to methods/functions. Parentheses could be used to enforce
access to property, e.g. ::($objA->methA) would evaluate the value stored
in the public property of the object $objA



This is precisely the kind of "solution" that I referred to as easy for 
the parser but confusing for humans.


::$objA->methA // method
(::$objA->methA) // method
::($objA->methA) // property
::($objA)->methA // method?
(::$objA)->methA // attempt to access a property of a Closure object?

It's just a mess, IMHO


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] [RFC] First-class callable syntax

[Kamil Tekiela]

Hi Nikita,

I would like to just express my feelings. It's a definite YES from me for
first-class callables. We need something to replace [$this,
'privateMethod'].
I just don't like the proposed syntax. The triple period '...' has a
meaning already and reusing the same syntax isn't nice.
I haven't followed the PFA RFC closely, but I don't like that proposal as
it seems to add additional complexity to PHP's syntax for little gain. I
feel like it's just arrow function on steroids.
I know we can already do something like this:

function do_stuff($e) { return $e**2; }
$result = array_map(do_stuff::class, [1,2,3,4]);

I wouldn't mind having a dedicated operator for creating closures in the
same way. e.g.
$result = array_map(do_stuff::closure, [1,2,3,4]);

I understand that ::class creates a string literal and ::closure creates
closure, but from the usability point of view, they would be used in
similar ways.

Many languages have shared symbol tables for constants, functions and
variables. PHP doesn't, so we can't just use the name, but I agree with
Rowan that just using a function's name would be ambiguous even if the
parser allowed for that. We could introduce new syntax for this. I think
Kotlin uses double semicolon in front of the identifier. e.g.
$result = array_map(::do_stuff, [1,2,3,4]);
This would be less confusing than the (...) syntax IMHO. Of course this
still has the same ambiguity as Rowan points out. Is ::$objA->methA a
property or a method? We could solve this problem by specifying the syntax
to always refer to methods/functions. Parentheses could be used to enforce
access to property, e.g. ::($objA->methA) would evaluate the value stored
in the public property of the object $objA

If we land on using the syntax as your RFC proposes then I would ask
Internals to avoid (...) and instead use another symbol inside the
parentheses. I believe any other symbol would look better than triple
period, e.g.  $objA->methA(*)

Kind Regards,
Kamil

Re: [PHP-DEV] [RFC] First-class callable syntax

[Rowan Tommins]

On 20/05/2021 19:16, Alexandru Pătrănescu wrote:

Also, considering the resolution between property and method (or between
constants and static methods) , it's clear that we need a syntax that looks
like the usual invocation:(...), or (?), (...?), ($), ($$), (...$) etc.



I'd like to expand on this point, because I'm seeing a lot of 
suggestions for syntaxes that overlook it.


The following are all valid, but refer to _different_ things called "foo":

foo // a constant called foo
foo() // a function called foo
$foo // a variable called foo

$bar->foo // a property called foo
$bar->foo() // a method called foo

Bar::foo // a class constant
Bar::foo() // a static method
Bar::$foo // a static property

The thing that consistently distinguishes function and method calls is 
the parentheses after them. This holds even for "exotic" combinations:


$foo() // a variable called foo, de-referenced as a callable and then 
invoked
($bar->foo)() // a property called foo, de-referenced as a callable and 
then invoked
foo()() // a function called foo, the return value of which is 
de-referenced as a callable and invoked


Any callable syntax (and, if/when we get one, a partial application 
syntax) that doesn't have the parentheses there is going to run into 
annoying edge cases fast. Not necessarily the kind of edge cases that 
are hard for the parser, but definitely the kind that are confusing to 
humans.



Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] [RFC] First-class callable syntax

[Larry Garfield]

On Thu, May 20, 2021, at 10:55 AM, Guilliam Xavier wrote:
> On Thu, May 20, 2021 at 5:12 PM Nikita Popov  wrote:
> 
> > On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes  wrote:
> >
> > > Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> > > this, this is just a method call… oh wait, it’s actually a callable”. It
> > > really makes my head hurt.
> > >
> >
> > Yes, I can see how that could be confusing. The current syntax is chosen to
> > be a subset of the partial function application proposal. However, I would
> > also be happy with some other syntax that makes it clearer that this is
> > acquiring a callable and not performing a call.
> >
> 
> Hi, several other syntaxes have been proposed to consideration in the PFA
> thread, and I wouldn't want to start new bikeshedding here; is there a
> place that would be more appropriate to gather the possibilities (like a
> kind of updatable list)?
> 
> Thanks,

There's been a lot of rapid iteration, experimentation, and rejection.  The 
most recent alternatives are this one from Levi:

https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd

And this one from me:

https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8

The main takeaways (to give context to Nikita's proposal):

* Because of optional arguments, using the same symbol for "copy one parameter 
from the underlying function" and "copy all remaining parameters from the 
underlying function" is not viable.  It runs into oddball cases where you may 
intend to only use one argument but end up using multiple, especially in array 
operation functions that sometimes silently pass keys along to callbacks if 
they can.  Hence the separate ? and ... that were proposed.

* Named arguments make things more complicated.  One of the questions is 
whether named placeholders should be supported or not.  And if they are, does 
that mean you can effectively reorder the arguments in the partial application, 
and what does that mean for usability.  It gets complicated and scope-creepy 
fast.

* The most important use cases are:
** "prefill nothing, just give me a callable" (which is the case Nikita's RFC 
covers) 
** "reduce an arbitrary function to a single remaining argument", which lets it 
be used by various existing callback functions in the standard library 
(array_map, array_filter, etc.), many user-space APIs, and the pipes RFC that I 
am planning to bring back up once PFA is figured out 
(https://wiki.php.net/rfc/pipe-operator-v2).  

While there are other use cases, the two of those cover the vast majority of 
uses.  (There is some dispute about which of those is larger, or will be larger 
in the future.)

It took a while to realize the first point, which basically killed "? means 
zero or more".  We also went down a rabbit hole of trying to make argument 
reordering work because some people asked for it, but as noted that's a very 
deep rabbit hole.

My gist above was a reduced-scope version of Levi's that uses two symbols and 
drops named placeholders.  It doesn't give us every possible combination, but 
it does give us most reasonable combinations.

Nikita's "just do the first one" RFC (this thread) was proposed at about the 
same time, and takes an even-further scope reduction.

My own take is that the PFA discussion has been overly-bikeshedded, which is 
unfortunate since I think we're quite close to now having a workable answer 
that covers most reasonable use cases.  While I agree Nikita's RFC here would 
be an improvement over 8.0, I don't think throwing in the towel on PFA yet is a 
good idea.  It's a much more robust and powerful approach that still gets us 
the "first class callable" syntax we all want (at least I assume we all do), 
and lots of additional power to boot.  I'd rather see us try to drive PFA home 
to completion.  If that proves impossible by early July, then this RFC would 
still get us something this cycle, as long as the syntax is still compatible 
with PFA.  (Otherwise whenever PFA gets sorted out in the future we end up with 
yet-more-ways to do the same thing that are not optimizations of each other but 
just competing syntax, in which case no one wins.)

--Larry Garfield

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

Re: [PHP-DEV] [RFC] First-class callable syntax

[Aleksander Machniak]

On 20.05.2021 19:05, Nikita Popov wrote:
>> $fn = ::myFunc;
>>
> Unfortunately, this syntax is trivially ambiguous. "$fn = &$this->myFunc"
> is currently already interpreted as a reference assignment of the property
> $this->myFunc.

could that be just fn(sth)? I mean without the => part.


$fn = fn($this->myFunc);

$fn = fn(myFunc);

$fn = fn(Foo::myFunc);

and then something like this

$partial = fn(Foo::myFunc)[?, 42];

or

$partial = fn(Foo::myFunc, ?, 42);


My earlier idea was that actually cloning a callable could convert it to
a Closure, but I'm not sure now:

$fn = clone $this->myFunc;


or is this a heresy? ;)

-- 
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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

Re: [PHP-DEV] [RFC] First-class callable syntax

[Alexandru Pătrănescu]

On Thu, May 20, 2021, 15:48 Nikita Popov  wrote:

> Hi internals,
>
> I'd like to present an RFC for a first-class callable syntax, which is
> intended as a simpler alternative to the partial function application (PFA)
> proposal:
>
> https://wiki.php.net/rfc/first_class_callable_syntax
>
>
This looks good to me. Following some discussions, I understand how this
syntax was proposed. Maybe update also the PFA RFC to be up to date with
the latest info.

Also, considering the resolution between property and method (or between
constants and static methods) , it's clear that we need a syntax that looks
like the usual invocation:(...), or (?), (...?), ($), ($$), (...$) etc.



I have few question related to some behavior.

If we have closure:
$c = function() {};

Will this be true?
$c(...) === $c;
similarly with how it happens for
Closure::fromCallable($c) === $c;
since the RFC makes a lot of comparisons between them.

Also, from performance point of view, do we expect the new syntax to behave
similarly?

And another not practical one:
Will this be valid?
$c(...)(...)(...)(...)();

Regards,
Alex

Re: [PHP-DEV] [RFC] First-class callable syntax

[Dan Ackroyd]

Ondřej Mirtes wrote:
> Hi, I’m confused by the syntax, when I read it,...

That is true of almost any new syntax. Some of us are still getting
used to seeing \ in front of function calls. It doesn't mean that the
syntax choice is a bad one, just that it's something new.

For me, the main questions I ask myself is:

* could I explain what the syntax means to a junior developer?
* would the junior developer be able to remember it?

For both of those questions, the suggested syntax seems fine.

Guilliam Xavier wrote:
> I wouldn't want to start new bikeshedding here; is there a
> place that would be more appropriate to gather the possibilities

Unfortunately I don't think we do have a better place. Being able to
fork conversations so that "not completely off-topic, but not really
that productive and getting in the way of the main discussion stuff",
can be out of the way, but findable, is a feature that would be really
useful for discussions.

Nikita Popov wrote:
> I am generally open to using a different syntax,

Well, you might regret saying that. It might not be appropriate*, but
having $() as marking a closure/callable seems 'clean' to me. Though
obviously novel and likely to cause gut reactions:

$(strlen);
$($foo, bar);
$(Foo, quux);
$($foo->fn);
$($foo);
$($fn);

Each would be equivalent to:

Closure::fromCallable('strlen');
Closure::fromCallable([$foo, 'bar']);
Closure::fromCallable([Foo::class, 'quux']); // aka
Closure::fromCallable('Foo::quux');
Closure::fromCallable($foo->fn);
Closure::fromCallable($foo);
Closure::fromCallable($fn);

For the code:

class Foo {
public $fn;
public function __construct($fn) {
$this->fn = $fn;
}
public function bar() {
}
public static function quux() {
}
public function __invoke() {
}
}

$fn = function() {
echo "I am function\n";
};

$foo = new Foo($fn);

cheers
Dan
Ack

* at least in the sense that it's a big syntax change, for a
relatively small feature.

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

Re: [PHP-DEV] [RFC] First-class callable syntax

[Matthew Brown]

On Thu, 20 May 2021 at 10:17, Ondřej Mirtes  wrote:

> Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> this, this is just a method call… oh wait, it’s actually a callable”. It
> really makes my head hurt.
>

I agree with the first point — slightly confusing initially, but I can see
myself get used to it. I suggested strlen(=>) as an alternative, not sure
if that would cause parsing difficulties.


> Also, static analysers already have to reason about current code, so
> PHPStan (and Psalm probably too) already supports referencing to callables
> as strings (global functions) and arrays (methods):
>
> $name = 'date';
> $name(1); // Parameter #1 $format of callable 'date' expects string, int
> given.
>

I disagree here: while Psalm can understand what's going on in the above
code, callables are definitely (in my opinion) the most hairy part of PHP's
type system.

The RFC gives an example of something not caught by either PHPStan or Psalm:

https://psalm.dev/r/21217fdfb4
https://phpstan.org/r/6cc8cdc2-ecc6-403d-887d-0f12f4813b75

Discouraging this particular formulation would make affected codebases safe
from this particular error.

Best wishes,

Matt

[PHP-DEV] Injection vulnerabilities

[Craig Francis]

Hi Internals,

Just something for you to think about, to start the conversation (as the
8.1 deadline is fast approaching).

Injection Vulnerabilities remain on the OWASP Top 10 List, same with XSS.

https://owasp.org/www-project-top-ten/2017/

These mistakes happen when user supplied values are included in command
strings - be that SQL, HTML, OS Commands (e.g. shell_exec), and dare I say
it eval().

It's easy to make these mistakes, especially when using a library (API)
that hides the implementation details.

I've got loads of examples (one of the joys of auditing), but have a think
about these 3 for now...

---

*1*, Let's consider an ORM (I'm using CakePHP this time). Parts of the
where() array must be defined by the programmer. Both of these examples
work, but the first one has a simple mistake that has introduced an SQL
Injection vulnerability:

$articles->find()->where(['id != ' . $_GET['id']]);

$articles->find()->where(['id != ' => $_GET['id']]);

https://book.cakephp.org/3/en/orm/query-builder.html

---

*2*, Maybe the programmer is writing the SQL themselves, and passes it on
to a basic database abstraction; but they don't realise the SQL string
should be entirely written by the programmer, using parameterised queries*:




$sql = 'SELECT * FROM table WHERE id IN (' . implode(',', $_POST['select'])
. ')';

* Yes, I know, things like table names cannot use parameters, but they have
to be handled carefully as well, and will be covered.

---

*3*, How about a small HTML snippet, which should also be written entirely
by the programmer:

$html = "";

Because escaping is hard (and sometimes completely forgotten), user values
should be added to HTML via a context-aware Templating Engine/Library (so
every one of the programmers using that well tested library don't have to
worry about making these mistakes all the time).

In this case, the src attribute value isn't quoted, and that kinda works,
but it can be exploited with $url = '/ onerror=alert(1)';

---

Just have a think about these issues, and note how they are all affected by
the same problem.

Craig

Re: [PHP-DEV] [RFC] First-class callable syntax

[Nikita Popov]

On Thu, May 20, 2021 at 6:22 PM Luis Henrique 
wrote:

> On 20/05/2021 12:55, Guilliam Xavier wrote:
> > On Thu, May 20, 2021 at 5:12 PM Nikita Popov 
> wrote:
> >
> >> On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes  wrote:
> >>
> >>> Hi, I’m confused by the syntax, when I read it, I think to myself “I
> know
> >>> this, this is just a method call… oh wait, it’s actually a callable”.
> It
> >>> really makes my head hurt.
> >>>
> >>
> >> Yes, I can see how that could be confusing. The current syntax is
> chosen to
> >> be a subset of the partial function application proposal. However, I
> would
> >> also be happy with some other syntax that makes it clearer that this is
> >> acquiring a callable and not performing a call.
> >>
> >
> > Hi, several other syntaxes have been proposed to consideration in the PFA
> > thread, and I wouldn't want to start new bikeshedding here; is there a
> > place that would be more appropriate to gather the possibilities (like a
> > kind of updatable list)?
> >
> > Thanks,
> >
>
> I am much more into advanced features of PFA, but is this case why not
> just use the & operator for "function reference" like C/C++? It is well
> known and solves the ambiguity with method/function call.
>
> $fn = &$this->myFunc;
>
> $fn = 
>
> $fn = ::myFunc;
>

Unfortunately, this syntax is trivially ambiguous. "$fn = &$this->myFunc"
is currently already interpreted as a reference assignment of the property
$this->myFunc.

I have updated
https://wiki.php.net/rfc/first_class_callable_syntax#syntax_choice to
discuss some of the obvious suggestions and why they don't work.

Regards,
Nikita

Re: [PHP-DEV] [RFC] First-class callable syntax

[Luis Henrique]

On 20/05/2021 12:55, Guilliam Xavier wrote:

On Thu, May 20, 2021 at 5:12 PM Nikita Popov  wrote:


On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes  wrote:


Hi, I’m confused by the syntax, when I read it, I think to myself “I know
this, this is just a method call… oh wait, it’s actually a callable”. It
really makes my head hurt.



Yes, I can see how that could be confusing. The current syntax is chosen to
be a subset of the partial function application proposal. However, I would
also be happy with some other syntax that makes it clearer that this is
acquiring a callable and not performing a call.



Hi, several other syntaxes have been proposed to consideration in the PFA
thread, and I wouldn't want to start new bikeshedding here; is there a
place that would be more appropriate to gather the possibilities (like a
kind of updatable list)?

Thanks,



I am much more into advanced features of PFA, but is this case why not 
just use the & operator for "function reference" like C/C++? It is well 
known and solves the ambiguity with method/function call.


$fn = &$this->myFunc;

$fn = 

$fn = ::myFunc;

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

[PHP-DEV] PHP 8.0.7RC1 Available for testing

[Sara Golemon]

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

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

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net
8.0.7 should be expected in 2 weeks, i.e. on June 3rd 2021.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/2e5c7a9d497fda62e10f6a76db43e490

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.7RC1.tar.gz
SHA256 hash:
d93e1f26cce090119fe43645da9f2493c720ce85d6744965fda143a5e7cdd416
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmClU7cQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgbKEADZBrs4j2azo4r4UheuhAmIYSqn9ey5N2Ea
+bwwR0hGXwofxZloBouviVsJbtHpdAqPNToiPGi1xYMrWE21NvN7rqZOFtF3MMhv
qlS/ziNTk45Q1q1fo7vJDNi8LjpP6VIVfAZYkfKvp0HSSca/DR+7S1I72rRQlVUp
o/3j+ZI8ZbH8kCzcqQ1FAKNHlwF+eR6sdi4ge0g7TIk0GkMmUuucTTjA+FzLZVk/
J/RVyUY9Gbr082feL4Oe5zxVM6pv3EzUfUnUCepyMPhsyE0YTI7ws61qtv9JuncQ
OMRp/xK2wIFs/VxmPXrg673iojCZFjugG0Q4BASpXfTN07MB1mCJoerMc8HxwZbH
qA39HHOyRUcqlzJm6OE2XPemg7swD2tuW/oaTSX6RWKLgr9biskrBA5v1znlxJ5P
+0Lv5ips8sT6ONf+p3rgwGO9byPMUi6N6U7zzKnZ9UswGsloK0xxFBm5G+pl8AVb
tC1DjUPDMK8bcZ57cUkNuqOtukPAhu6BRVpkQ+1xogQLMvpMxIkHPvtX+MQ9w6Lf
EtPr2FHPDqGF1UvCcTcCM6qDArYvpJab8JjmzR+Hsq0B6j1hA1XZPSovcZzUuR6Q
G9OH/0AyuHQlPU0ZhVjqy5JiZitvPvlAxwimmuvvBrBQa6UI4ViDZVbLyV2bKOlQ
W5YLzg3MUQ==
=TW/v
-END PGP SIGNATURE-

php-8.0.7RC1.tar.bz2
SHA256 hash:
3e114755059c204af29a2f1044f7001ce42773ae10f5d6657b730ee11356b1d2
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmClU7cQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhchOOEACo7tUxZHFodvS8N0jCBskTTWzaUrEe3w6H
ez0pDBMfLng8CzS1sOed5MPY5p1AIttQMlLvWciUKK4ru328LoaJXrKfdIh4sGfH
13Tg1WS6ELdC+nQw5S05F7FxxqtD9w9czMeHbAoBReB0f3YcqtoCsyPhV92t1AeK
opb3NWjpuuXbSBjXadYMLGtryeYtzUHR0b8dsXIFPHqNSDIIa/N3kEFkbiAe0znQ
8cdjdmd32gTdlZ40akHQ/AX648VhpBtotl/OV96wB9UreuflbDeueidQvukQu0Ab
lDKelR9q6OKa9HvB1zfMt11hrc0oDL0Dnlz06jeZMjQU6sCCEKbyIZ6FYuwB7GtY
tN+LtZbf68beyMUk6y9lubB+mej8HQqeClXXxTX3dGWC6EIdlrj4W4RJ0u++ZDqE
RG0kI4acqX6+rj2p8H1LxxZoSxWclsjZUYWFVyyRRNUstbSEroOM5OLSLoRGEQjf
Cf/UmsUh2IgBj1V70IFvny6u8VXsjWSyavs+uv5ZwtGwtHyu2NoH30ThD3lLuAoX
BArrQYb6+MPhJumYnnvTWit+nLYRqljRK11i3WNztyHUj5NswU5joNBEbRS8kZhO
0Prgku3lY9sc0lNJds/XurpFeB55qgIeuvzXaVOoXp4S4e+xyAWYE7Mkm8MEeB6V
BbrWxnmaMQ==
=/wdh
-END PGP SIGNATURE-

php-8.0.7RC1.tar.xz
SHA256 hash:
86371e7cf3d9bb3831b68d0615aa3c6a989554022096c63c8f7eefd3b5c43575
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmClU7cQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhckiPD/9rgOrqxuscO/R787ckNEZFazAZQbaXtFs9
oaojKOqcrHoJOsxWJRvrq6syuUuDsNpJuxRN6pfzuTwhgTHxorv7ZjGiSwBt8Gdj
s5cFROkrxr4fJY/H2o941V839T73cq2h6sb/5y2TEHWxm8DoJq5wI5jGXfUtr0Kw
a0VzQ7pfhojFj+tONz4TMz4Gty5nIz/iQ8uzm4gLf7foruEU23mffTFHFeNSS3ox
hZhq5JeCuuo8oyz7Lfd3ZXW+09Vu5w/plspqa8kL9BDn60aOVJC5f/vKDLSzVuvd
wJ/IMl8LAUAAQZuCJZ7F6USk8AU07ksUwGvzqXUbB9rThJTeApb4c0YQ5uV2Gvkf
+NAN6eMSN/PwUpwyUO/9tB041osBG/nH6Zz8hU/Lejo9bPSG/xQEozg9gR0zwUPJ
g0YdUCLnGhB47vG9B44ptcVcU1Hht0jK5VjQuVtkbVKkih7Tboi05w3sZdjuyM7K
z6TI3yJBmC+0QvFk6DPgo1JJCnA4Hu+tfGYq617bkWqJv3cH5sbgU111yOL9Xlf0
KZUX+D4CT4YrtEYRA/Xl9lwR+PgcWX3Z8FUOMBTquUYYIiHcj10PD56At5nf/teT
iBk/lqlsu5Gajhh8Sm4/G60Bdb/exZw35s3arE+S1roKC0Z6CSEtGP+je+XIp5cr
fE8xYaIYZw==
=ZIq+
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] First-class callable syntax

[Guilliam Xavier]

On Thu, May 20, 2021 at 5:12 PM Nikita Popov  wrote:

> On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes  wrote:
>
> > Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> > this, this is just a method call… oh wait, it’s actually a callable”. It
> > really makes my head hurt.
> >
>
> Yes, I can see how that could be confusing. The current syntax is chosen to
> be a subset of the partial function application proposal. However, I would
> also be happy with some other syntax that makes it clearer that this is
> acquiring a callable and not performing a call.
>

Hi, several other syntaxes have been proposed to consideration in the PFA
thread, and I wouldn't want to start new bikeshedding here; is there a
place that would be more appropriate to gather the possibilities (like a
kind of updatable list)?

Thanks,

-- 
Guilliam Xavier

Re: [PHP-DEV] [RFC] First-class callable syntax

[Nikita Popov]

On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes  wrote:

> Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> this, this is just a method call… oh wait, it’s actually a callable”. It
> really makes my head hurt.
>

Yes, I can see how that could be confusing. The current syntax is chosen to
be a subset of the partial function application proposal. However, I would
also be happy with some other syntax that makes it clearer that this is
acquiring a callable and not performing a call.


> Also, static analysers already have to reason about current code, so
> PHPStan (and Psalm probably too) already supports referencing to callables
> as strings (global functions) and arrays (methods):
>
> $name = 'date';
> $name(1); // Parameter #1 $format of callable 'date' expects string, int
> given.
>

This is only possible for static analyzers that implement relatively
sophisticated and non-local analysis. If you see a random ['A', 'b'] in the
code, you cannot know whether this is just an array, or supposed to be a
reference to A::b() without following the data-flow of the value, and
checking whether it is going to be used in a position that requires a
callable, or passed to a callable parameter.

This means that answering a simple question like "find all references to
this method in the code base" also requires solving data-flow and type
inference problems, which is ... not great.

Apart from the static analysis perspective, having a first-class callable
syntax also fixes the current scoping problems that plague callables (which
can be worked around using Closure::fromCallable), and allows the
elimination of the callable type in favor of the Closure type, which has
much more well-defined semantics. (You will note that callable is already
not usable for typed properties.)

I don't think there's any question that we need a first-class callable
syntax ... it's more a question of how exactly it should look like. The PFA
RFC proposed one possibility. This RFC is another, more limited form.

Some people have also suggested that we should "just" allow writing strlen
to reference the strlen function etc, but this is not viable without a
prior unification of all symbol tables (such syntax conflicts with constant
access, class constant access and object property access).

Regards,
Nikita

Re: [PHP-DEV] [RFC] [Draft] Add RNG extension and deprecate mt_srand()

[Guilliam Xavier]

On Thu, May 20, 2021 at 2:42 PM Go Kudo  wrote:

> Sorry. I couldn't make it in time for my lunch break.
>

No worries, there was quite a lot to read/reply ;)


> >  How many bytes is `Source::next()` supposed to generate? Is it even
> intended to be called directly (vs `Randomizer::generateBytes(int
> $length)`)?
>
> No, this is not intended to be used directly.
> In fact, as many people have pointed out, I think it would be more
> appropriate to merge it into a single class.
>
> As per the original implementation (ext/orng), I didn't think it needed to
> be separated originally. One of the comments on a previous RFC suggested
> that it would probably be better to separate them, and I took that into
> account.
>

I see. Sorry that you had so many back-and-forth suggestions :s I guess
that the simplest-to-use API (for the main intended/expected use cases) is
more likely to get acceptance.


> > About the `MT19937PHP` variant: The PHP manual for `mt_srand()`
> describes the `MT_RAND_PHP` mode like this: "Uses an *incorrect* Mersenne
> Twister implementation which was used as the default up till PHP 7.1.0.
> This mode is available for backward compatibility."; do we really need/want
> to port it to this new extension?
>
> This is for backward compatibility. If it is not needed, we would like to
> eliminate the implementation itself.
> Well, to keep the language core clean, maybe this should be provided by an
> appropriate external extension.
>

Yes, I think that a new core extension for PHP 8.1 needn't [or even
shouldn't] provide BC for an incorrect implementation that is not used
anymore since PHP 7.1 (unless someone here argues?).


>
> - `PlatformProvided` feels like the "odd one out" here: its constructor
> [assuming same as previous RFC] doesn't take a seed, and it isn't
> serializable; I understand why, but the main point of the RFC is "RNG
> reproducibility", which this class cannot achieve.
>
> You're absolutely right. I would like to remove this.
>

*Caution though:* after your recent discussion with Rowan, if you remove
the "change shuffle()/str_shuffle()/array_rand()'s internal
RNG from mt_rand()-like to random_bytes()-like" part from the proposal,
then this class becomes potentially "useful" again, not for reproducibility
but for shuffling an array/string by a "truly random" [actually CSPRNG]
algorithm, isn't it?


>
> > Technical, about `Randomizer::generateFloat()`: Is the returned float
> guaranteed to be finite (i.e. never NAN nor +/-INF)? And may it ever return
> -0.0 (negative zero)? and even if not, is 0.0 twice as likely as other
> floats?
>   Also, no `generateFloat(float $min, float $max)` variant like for
> `generateInt()`?
>
> As a matter of fact, we believe that the functions provided by this class
> are sufficient for `mt_rand()`, `shuffle()`, `str_shuffle()`, and
> `array_rand()` equivalents. At most, the equivalent of `random_byte()`
> might be provided.
> I'll reorganize these.
>

Sorry I'm not sure to understand your answer here, are you planning to
remove generateFloat() and generateBool()?
Well if generateBool() is a shorthand for `(bool) generateInt(0, 1)` [or
`generateInt(PHP_INT_MIN, PHP_INT_MAX) >= 0`] then it's not necessary, but
maybe convenient?
As for generateFloat(), I didn't know if you intended something like
`(float) generateInt(PHP_INT_MIN, PHP_INT_MAX) / PHP_INT_MAX` or rather
"call generateBytes(8) then reinterpret those 64 bits as an IEEE 754 double
[in C, not PHP]"?
But it's true that I haven't seen many people requesting new
"random_bool()" and/or "random_float()" functions, so...

By the way, for `generateInt()` (without explicit $min/$max args), I assume
that $max defaults to PHP_INT_MAX, but does $min default to PHP_INT_MIN or
actually 0 [if it's like [mt_]rand() I guess that the answer is probably 0,
but that could be written clear in the RFC]?


>
> Thanks for the detailed remarks. Based on these, I would like to clean up
> the RFC.
>
> Regards,
> Go Kudo
>

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] [RFC] First-class callable syntax

[Ondřej Mirtes]

Hi, I’m confused by the syntax, when I read it, I think to myself “I know
this, this is just a method call… oh wait, it’s actually a callable”. It
really makes my head hurt.

Also, static analysers already have to reason about current code, so
PHPStan (and Psalm probably too) already supports referencing to callables
as strings (global functions) and arrays (methods):

$name = 'date';
$name(1); // Parameter #1 $format of callable 'date' expects string, int
given.

[PHP-DEV] [RFC] First-class callable syntax

[Nikita Popov]

Hi internals,

I'd like to present an RFC for a first-class callable syntax, which is
intended as a simpler alternative to the partial function application (PFA)
proposal:

https://wiki.php.net/rfc/first_class_callable_syntax

See the Rationale section for details on how this relates to PFA. Over the
past week, we've had a lot of discussions on how exactly PFA is supposed to
work (most of them OTR), and while we seem to have a tentative consensus on
the correct model to use (which does not match the current RFC), it's clear
that this feature has turned out more complicated than originally
anticipated. Joe (who provided the implementation for the PFA RFC) is also
concerned about the implementation complexity that the final model would
require.

At least I personally was mainly interested in PFA because it provides a
first-class callable syntax as a side-effect. This RFC goes back to
providing *just* that. The syntax is forward-compatible with a future PFA
proposal though.

Regards,
Nikita

Re: [PHP-DEV] [RFC] [Draft] Add RNG extension and deprecate mt_srand()

[Go Kudo]

Thank you. I'm convinced for the most part.

I will probably have to separate this into a separate RFC. I'd like to
remove the existing reference to `mt_rand()` from this RFC, and not include
the BC break.

Regards,
Go Kudo

2021年5月20日(木) 17:46 Rowan Tommins :

> On 20/05/2021 05:59, Go Kudo wrote:
> > Thanks.
> >
> > Deprecation will be done only to prevent unintended MT state dependent
> > code. We don't plan to go as far as removing the implementation for now.
>
>
> I think every deprecation notice should mean a plan to remove. If you
> just want to encourage people to discover the new functions, I'm not
> sure a message in their logs every time mt_srand runs is the right way
> to do it.
>
>
> > > Firstly, making these functions independent of mt_srand() is a
> > breaking change, so cannot happen until PHP 9.0 at the earliest.
> >
> > To be honest, I don't understand how far PHP is willing to go to
> > accept disruptive changes.
>
>
> The official policy is here: https://wiki.php.net/rfc/releaseprocess It
> relies on the phrase "backwards compatibility", which is admittedly
> quite hard to define.
>
> You are right that the change from using rand() to using mt_rand() in
> 7.1 is arguably not backwards compatible. However, the following code
> can be used to reproducibly shuffle two arrays in any version of PHP:
>
> srand(123456);
> shuffle($array1);
> shuffle($array2);
>
> The exact sequence returned will be different in 7.1 from 7.0, but
> because srand() is now an alias of mt_srand(), it still affects the
> shuffle() function in the expected way. If we switch shuffle() to an
> algorithm that can't be seeded at all, this code will simply stop
> working, and have to be completely rewritten.
>
> A "polyfill" of sorts is possible, by storing an instance of the new
> RNG\Randomizer in a global or static variable, but it's more than just a
> find-and-replace, especially since many users will need to support
> version 8.0 and 8.1 in the same code base.
>
> As I said previously, I'm not convinced these functions need to stop
> using the MT algorithm at all, and certainly see no reason to rush the
> change.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Draft] Add RNG extension and deprecate mt_srand()

[Go Kudo]

Sorry. I couldn't make it in time for my lunch break.

>  How many bytes is `Source::next()` supposed to generate? Is it even
intended to be called directly (vs `Randomizer::generateBytes(int
$length)`)?

No, this is not intended to be used directly.
In fact, as many people have pointed out, I think it would be more
appropriate to merge it into a single class.

As per the original implementation (ext/orng), I didn't think it needed to
be separated originally. One of the comments on a previous RFC suggested
that it would probably be better to separate them, and I took that into
account.

> About the `MT19937PHP` variant: The PHP manual for `mt_srand()` describes
the `MT_RAND_PHP` mode like this: "Uses an *incorrect* Mersenne Twister
implementation which was used as the default up till PHP 7.1.0. This mode
is available for backward compatibility."; do we really need/want to port
it to this new extension?

This is for backward compatibility. If it is not needed, we would like to
eliminate the implementation itself.
Well, to keep the language core clean, maybe this should be provided by an
appropriate external extension.

- `PlatformProvided` feels like the "odd one out" here: its constructor
[assuming same as previous RFC] doesn't take a seed, and it isn't
serializable; I understand why, but the main point of the RFC is "RNG
reproducibility", which this class cannot achieve.

You're absolutely right. I would like to remove this.

> Technical, about `Randomizer::generateFloat()`: Is the returned float
guaranteed to be finite (i.e. never NAN nor +/-INF)? And may it ever return
-0.0 (negative zero)? and even if not, is 0.0 twice as likely as other
floats?
  Also, no `generateFloat(float $min, float $max)` variant like for
`generateInt()`?

As a matter of fact, we believe that the functions provided by this class
are sufficient for `mt_rand()`, `shuffle()`, `str_shuffle()`, and
`array_rand()` equivalents. At most, the equivalent of `random_byte()`
might be provided.
I'll reorganize these.

Thanks for the detailed remarks. Based on these, I would like to clean up
the RFC.

Regards,
Go Kudo

2021年5月19日(水) 18:46 Guilliam Xavier :

>
>
> On Tue, May 18, 2021 at 6:19 PM Go Kudo  wrote:
>
>> Hello internals.
>>
>> I have created a draft of the RFC.
>>
>> https://wiki.php.net/rfc/rng_extension
>>
>
> Hello Go Kudo,
>
> First of all, thank you for the (re)work.
>
> I think the API looks better, but I still have some remarks/questions
> (roughly in order of appearance, with some overlap):
>
> - How many bytes is `Source::next()` supposed to generate? Is it even
> intended to be called directly (vs `Randomizer::generateBytes(int
> $length)`)?
>
> - The stubs in "Proposal" should show `__construct()` signatures for the
> classes implementing `Source`.
>
> - About the `MT19937PHP` variant: The PHP manual for `mt_srand()`
> describes the `MT_RAND_PHP` mode like this: "Uses an *incorrect* Mersenne
> Twister implementation which was used as the default up till PHP 7.1.0.
> This mode is available for backward compatibility."; do we really need/want
> to port it to this new extension?
>
> - I think you said in the past that `XorShift128Plus` should be the
> preferred/default implementation, and `MT19937` is only provided for
> compatibility/migration? But if so, that's not clear at all in the RFC.
>
> - `PlatformProvided` feels like the "odd one out" here: its constructor
> [assuming same as previous RFC] doesn't take a seed, and it isn't
> serializable; I understand why, but the main point of the RFC is "RNG
> reproducibility", which this class cannot achieve.
>   Also, we already have `random_bytes()`/`random_int()`, and you're
> proposing to change `shuffle()`/`str_shuffle()`/`array_rand()`'s internal
> RNG from `mt_rand()`-like to `random_bytes()`-like, so what reason would
> there be to use this class? only `generateFloat()`? but couldn't that be a
> new global function `random_float()`?
>   All in all, wouldn't it be simpler to drop `PlatformProvided`, and have
> all `Source` implementations take a seed on construction and be
> serializable?
>
> - Technical, about `Randomizer::generateFloat()`: Is the returned float
> guaranteed to be finite (i.e. never NAN nor +/-INF)? And may it ever return
> -0.0 (negative zero)? and even if not, is 0.0 twice as likely as other
> floats?
>   Also, no `generateFloat(float $min, float $max)` variant like for
> `generateInt()`?
>
> - **About main usage of the API:** To get e.g. $n (say 3) pseudo-random
> integers between $min (say 0) and $max (say 100) using the "best"
> implementation (which we have to know/guess is XorShift128+, isn't it?), we
> must: *first* choose a $seed (`time()`, maybe?), *then* do `$source = new
> XorShift128Plus($seed);` *and* `$rng = new Randomizer($source);` [even if
> $source (and $seed) could be inlined, that's still several "steps"], *then*
> we can finally call `$rng->generateInt($min, $max);` $n times. Is that
> correct?
>   If so, it may make sense from 

[PHP-DEV] PHP 7.4.20RC1 is available for testing

[Derick Rethans]

PHP 7.4.20RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.4.20RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system at
.

Hash values and PGP signatures can be found below or at
.

7.4.20 should be expected in 2 weeks, i.e. on June 3rd, 2021.

Thank you, and happy testing!

Regards,
Derick Rethans


php-7.4.20RC1.tar.gz
SHA256 hash: 0cce2a96e8cb80d0164c4db7117213c8f2c0abb50e3f5d89ac70b404a99749fd
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmCjtiYACgkQkQ3rRvU+
oxJ02xAAo9dStQC+yajybGNI9M+tfMkU+hOspJuS7xFI8A8HsB/FQZ4TTkm93b7C
YglsgfUrMNozBa1V/j3EaVs3hlvvA+/GVFY7LlD4tsoIiwqwbLZEjJdjSquOYwN/
sWw64mAUDsK0B9jP+myQSiHiM/zpuVsXnCg78VW/dOUraYdbWRgEpKRig/Io1NWW
0HL3x9ooZc5zO02RIZ35Jo00vpCTt1wPXfceLXoQYqRrNBdFIbpK3SNBoL5ojVpc
gOtmCnjhOW7/CqGEKJU7DZ7ql0GR6tVEjoLStrPIAMVD4BHDP3ImDaF2HpNcaVZ3
NgX53UH5tMFPat7crKsPifM0OTFajO0xMMD3n8C75il8J8RTtZQOmTBrgXQ+ny4P
FnUi3gppL7mP6wg6a2MijkxQ511Xhm7kNBdOMDIBOjZZiqndZ8jTkQZQffIJfWsd
DJgLQDiSsrPPz49AfRcHA4D/RFI5jo+vSMEI+rCwvJOJlEQzUQcgT39SAbSEA1x9
wjLlKFe4yJTbuDmNcL5Q7/M4Zs6mj7UQKc4nb7ZGE0Rfd5IllV6RPyYiFsTq1Odi
/L8Eh8xqPJxsmG1CfRVp8HB5A24qn8dnxafksiKD/mbpWfm2HtkzRWBQ35P2Q2fR
T4pZkg0chu0qGXbAj9BgqqJjmWomFzBTJ4DfhG++1Wz4f397qK8=
=woHD
-END PGP SIGNATURE-

php-7.4.20RC1.tar.bz2
SHA256 hash: d1ec6a696be8908f843c1d43da718264c5157524de895a6e668a9af41191412f
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmCjtioACgkQkQ3rRvU+
oxI6hg//R7453f3d6kWX64jcOoBnboGkjZtSXPnDAF3e2A4F0+PbtGiCDN7ECUqE
cD80I45T5vIhaHZgbTAYObgZbqTKWOsgqT018GQlImFUFaFALFVivkmqz5ixlPhJ
fh2RdEXi7xX7NM/toyactYLiJ+6rXmK0InDZWe9Lz0X8uvCFpFq8yqHcfkxBDPel
iGHbL24cROWpi05sbmzl2ptETCjDxf4lzMu1BbiJbrJqMq6aQEyVipEyMgw0w+gz
86FXgHCxfZQ4JxNE7F0izkD1wDBEer9Go/9oV1xAzAyy3am0RNAPOP8RgVfIeCny
EN3GlNtOs0pJQ0bet5N34y4si5p09FVHlVwgOpn0GXmuVjsCF/rAAmHs6KPxLK4E
XYSVI6DXGGqd4QRZvqghFjuxwkWW5T57/AWaHSMwFuddGPT67psaBET6bep8wL9N
9Q0ysKvkHNCaesrDk84madhu2O/B7VXqBcNAaY7KVcceYlC/T4FZxaf42sjqBJFG
WJSnWM+4oTBUvaQv0VIcxuRU162FOObuUiujpaPAV3GN6E00EgjGFW8zB5yVibVI
Rj/GX15r+mAx1pImNEI1SxcU59UTypf8MZfWRryKrRYxH7hNeq+s5FFNOTALD9CP
vi6BzbBW8AWE+2Ql+rtoBUjAwm8YrZRIKhwVhVe3B7XjRrgM910=
=oBw4
-END PGP SIGNATURE-

php-7.4.20RC1.tar.xz
SHA256 hash: a1907799e18073b3ed406f3255cae5867283ee4fe60ccbb36902c8071f6edfda
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmCjtioACgkQkQ3rRvU+
oxIgORAA1A9cnzIyhC4PhL1WMmboPVUOj4B58TQjyNucnvueYW6PPelaWtqthpoB
O1fHT5k6tm3dVDvG5d1Ao7uO9jSjVVS6hscAd9H17NmBgp4d8GIr4y14sJO1X2CM
6EiZtqJ0ktLmPzSIjcus7LDxtgCINXro7CUOuuZGs86BpkXLZlN3BH4HrmOApUyg
CHG2r6WHKZIhzY88pZLvt31hZvnagkrpVJ/2O7AIMDLL6jdKEWYBI9ClnCHxmthL
RixHMWkrIH/BlItF5kbHlUyJvjcVe4m8WbBR/2wJCaVe+ZTzFtPctHajyEpnEN9S
mkRuPDlKH8d/BT4dYLqQ+9pHGM6O5R+SIIGoraTASOf30HcsaItt0PabdLMnxoMx
4cE70dI7oPnRf/XfiZgvl574lXzkP020cvfLxt3jlGN7AP510kG2mWWOvru78Q/X
hmnxrQUhpJml/KUS/Cg7h/LoMMxK8phS9qVN/4JdB//saioRPON2jIDRtHq3zQDz
pRYpscSGg9Ihlb9DQqPTh631qJRzL89+M/2iW4IZRjOkUQ+bGsC8BE/eqRHyuU6Y
5ToYFvYC9jzdwLB4Q3JdcNG2iNdtrPAs9sY0CNDUR3prZ/R/6CoLrzTDYsQ6r1pI
lF1HN2KX+mtfd6ovUGvSxjjKkldB/mjzIyJnn3QcWZ11+9glQnw=
=574g
-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] [RFC] [Draft] Add RNG extension and deprecate mt_srand()

[Rowan Tommins]

On 20/05/2021 05:59, Go Kudo wrote:

Thanks.

Deprecation will be done only to prevent unintended MT state dependent 
code. We don't plan to go as far as removing the implementation for now.



I think every deprecation notice should mean a plan to remove. If you 
just want to encourage people to discover the new functions, I'm not 
sure a message in their logs every time mt_srand runs is the right way 
to do it.



> Firstly, making these functions independent of mt_srand() is a 
breaking change, so cannot happen until PHP 9.0 at the earliest.


To be honest, I don't understand how far PHP is willing to go to 
accept disruptive changes.



The official policy is here: https://wiki.php.net/rfc/releaseprocess It 
relies on the phrase "backwards compatibility", which is admittedly 
quite hard to define.


You are right that the change from using rand() to using mt_rand() in 
7.1 is arguably not backwards compatible. However, the following code 
can be used to reproducibly shuffle two arrays in any version of PHP:


srand(123456);
shuffle($array1);
shuffle($array2);

The exact sequence returned will be different in 7.1 from 7.0, but 
because srand() is now an alias of mt_srand(), it still affects the 
shuffle() function in the expected way. If we switch shuffle() to an 
algorithm that can't be seeded at all, this code will simply stop 
working, and have to be completely rewritten.


A "polyfill" of sorts is possible, by storing an instance of the new 
RNG\Randomizer in a global or static variable, but it's more than just a 
find-and-replace, especially since many users will need to support 
version 8.0 and 8.1 in the same code base.


As I said previously, I'm not convinced these functions need to stop 
using the MT algorithm at all, and certainly see no reason to rush the 
change.



Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] [RFC] [Draft] Add RNG extension and deprecate mt_srand()

[Alexandru Pătrănescu]

On Tue, May 18, 2021 at 7:19 PM Go Kudo  wrote:

> Hello internals.
>
> I have created a draft of the RFC.
>
> https://wiki.php.net/rfc/rng_extension
>
> This RFC is a proposal to implement the old object scope RNG in PHP.
>
> You can read about the discussion so far below.
>
> - https://externals.io/message/114378
> - https://externals.io/message/112819
>
> I believe that the problem with the previous RFC was that it was just an
> ugly API. I propose to sort this out and deprecate the existing functions
> that should be replaced.
>
> I would like to ask for feedback on this draft RFC.
>
> Regards,
> Go kudo
>

This looks good.

1. instead of ext/rng and the RNG namespace, why not use ext/random and
Random namespace. And incorporate also other random_* functions maybe by
creating some aliases.

2. instead of  Randomizer, maybe we can use just Random or RNG (if previous
suggestion does not stand).

3. maybe some helper functions like Random\new_random($algo, $seed):
Random\Random can be used as a factory for internal implementations. Or
RNG\new_randomizer ($algo, $seed): RNG\Randomizer (if previous suggestions
does not stand).

4. for public function next(): string, how many bytes should be returned?

Regards,
Alex