Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Levi Morrison via internals]

> 3. Better visibility from the JIT (not having to cross userspace/internals
> border is good)

This is a good point _in theory_, but to me this is just indicative
that we need to be able to bundle built-in functions for php-src. Now
that we have preloading, I wonder how far off we are from achieving
this in some form.

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[John Bafford]

Hi everyone,

Apologies for not including context and responding to 40 emails all at once, 
I’m not at a computer (and won’t be for a few weeks).

Given the comments I read in the thread, I wanted to make some key points that 
I hope will clarify my intent behind the proposal:

* The primary motivation behind this RFC is the ability to indicate intent when 
iterating over a collection without caring about its values. Any performance 
benefits are strictly secondary.

* I explicitly chose void, rather than null, because in PHP, null is a value, 
and personally, I found it exceedingly weird to write `foreach($arr as $key => 
something-that-is-normally-a-value-except-in-this-case)`. In fact, if I’m 
remembering correctly, I actually waited until PHP 7.1 added `void` for this 
RFC specifically so I wouldn’t have to invent new syntax.)

* If PHP had either convention or special handling for _ or $_ as a “ignore 
this” destination, I wouldn’t have made the proposal.  However, it doesn’t; _ 
can (apparently!) be a constant, and is also a function, and $_ has no special 
handling (and I bet it’s actually used to contain values that are used in at 
least one application).

* From my recollection, unless something has changed drastically since 7.0 and 
8.x, the only possible performance hit from the patch would be in the parser, 
as there is obviously some additional logic. However, at runtime, it can only 
be faster, because in the presence of a `void` foreach value target, the parser 
simply doesn’t emit the opcode for writing a value there.

* I know it’s popular to say that `foreach(array_keys())` is rare; however, 
_every_ PHP application I’ve ever touched uses it at least once, and often 
multiple times. So, I’m equally surprised to find that there are people who 
have never used it. (If I had to guess, it’s that I make heavy use of the fact 
that arrays are ordered maps, and so, simply the keys and their order _are_ 
often a significant and useful piece of information on their own, especially in 
arrays that are used as mapping tables.)

I think that covers all the criticisms I saw, but if I missed anything, please 
let me know and I’ll respond once I have a chance. After I get back home, I’ll 
update the RFC with the results of this thread and bring it to a vote.

Thanks,

-John

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Josh Bruce]

> 
> In terms of readability, I'm more likely to do
>  $keys = array_keys($array);
>  foreach($keys as $key){

Fair point. I would too.

I have actually forgone even grabbing the keys and just using the loop without 
touching value in the body. 

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

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Kalle Sommer Nielsen]

Den tor. 3. sep. 2020 kl. 15.18 skrev Nikita Popov :
> The main thing I'm concerned about is that once we start extending this
> area (I assume that any & all are not going to be the last additions in
> this space) we will quickly run into function names that are either too
> generic or outright collide. For example, what if we want to add an
> iterator-based version of range()? Do we *really* want to be forced to pull
> a Python and call it xrange()? That's about as good as real_range()...

I agree with this point, and we already have some `iterator_*`
functions in ext/spl. Such as `iterator_to_array()`,
`iterator_count()` and `iterator_apply()`, so that prefix is somewhat
available to use for consistency.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Chase Peeler]

On Thu, Sep 3, 2020 at 12:05 PM Sara Golemon  wrote:

> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues 
> wrote:
>
> > Do you think that it could be proxied? I mean, optimize foreach
> > (array_keys()...) syntax to not call array_keys() in fact, but a
> optimized
> > version of foreach to handle key only. I don't know it opcache could do
> > that, and if it already does.
> >
> >
> I wouldn't use the word "proxied", but yes. In my mind the compiler would
> see:
>
> foreach(\array_keys($arr) as $key) {
>
> and quietly transform that into:
>
> foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
> {
>
>
Are there other instances where we have optimizations like this? If so, are
they documented?

In terms of readability, I'm more likely to do
  $keys = array_keys($array);
  foreach($keys as $key){

That would obviously break the optimization we're talking about though.
Which makes me wonder if there are other places like that.


> Thus not iterating the array twice and creating a temporary array of key
> names.
>
> -Sara
>



-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Dik Takken]

On 02-09-2020 19:13, Nikita Popov wrote:
> 
> Introducing special syntax for this has costs, both in terms of language
> complexity and in terms of implementation complexity. For example,
> implementing this feature will make foreach (whether or not the value is
> ignored) marginally slower, because we will have to explicitly distinguish
> this case. (Or alternatively, we'd have to specialize and increase VM code
> size -- it's not free in any case.)
> 

Regarding the performance / complexity concern, just some possibly naive
idea from a non-expert: Could this not be implemented in the compilation
phase only, without changing any of the run time code? Maybe the 'void'
could be compiled into an opcode sequence that still introduces a
variable holding the keys. Execution remains unchanged. So the only
thing that 'void' does is ask PHP to implicitly create a hidden variable
in stead of the programmer explicitly creating a visible one.

Ok, now just say "That's nonsense" and I will shut up. :)

Regards,
Dik Takken

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

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[David Rodrigues]

Just to I know, it can't be done by an intermediary method like my previous
example? Why are the limitations to that?

About PR, could you provide some additional tests?

Thanks!

Em qui, 3 de set de 2020 13:37, Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> escreveu:

> The goal is to be able to access the original object and it's id/hash.
>
> Usecases:
>
> - something is associated with the object using the object id/hash and
> it needs to be cloned as well
>
> we need the original object to obtain it's id/hash for spl_object_id and
> spl_object_hash methods
>
> - bounded Closures ar associated with the original object and they needs
> to be rebound to the cloned object
>
> example:
>
> public function __clone(self $origThis)
> {
> if ((new \ReflectionFunction($this->fx))->getClosureThis() ===
> $origThis) {
> $this->fx = \Closure::bind($this->fx, $this);
> }
> }
>
> Modification of php is simple:
>
>
> https://github.com/php/php-src/pull/6063/files#diff-beea8c5a8ceb318220b34b73e4ecfc98R252
>
>
> we simply pass the old object as 1 parameter. I belive, passing old
> object have positives and no performance nor compatibility impact. All
> other current solutions require an extra property and a lot of code, as
> assigning in constructor is not enough (due serialization etc.), or it
> is even impossible, if object was created using reflection without
> constructor.
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
> Michael Voříšek
>
> On 3 Sep 2020 18:00, Sara Golemon wrote:
>
> > On Thu, Sep 3, 2020 at 10:40 AM David Rodrigues 
> > wrote:
> >
> >> Now I rethinked about what I said. Really, maybe clone is not the best
> >> option. So maybe we can just use a method that will clone and will have
> >> access to both informations. But I don't know if it solves the original
> >> message.
> >>
> >> public function getUserCopy() {
> >> $userCopy = clone $this;
> >> $this->copies[] = $userCopy;
> >>
> >> return $userCopy;
> >> }
> > If your goal is to track copies, then a static makes much more sense.
> >
> > class AllKnowing {
> > private static $copies = [];
> >
> > public function __construct(...) {
> > self::$copies[] = $this;
> > 
> > }
> >
> > public function __clone() {
> > self::$copies[] = $this;
> > }
> > }
> >
> > -Sara

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[Michael Voříšek - ČVUT FEL]

The goal is to be able to access the original object and it's id/hash. 

Usecases: 


- something is associated with the object using the object id/hash and
it needs to be cloned as well 


we need the original object to obtain it's id/hash for spl_object_id and
spl_object_hash methods 


- bounded Closures ar associated with the original object and they needs
to be rebound to the cloned object 

example: 


public function __clone(self $origThis)
{
   if ((new \ReflectionFunction($this->fx))->getClosureThis() ===
$origThis) {
   $this->fx = \Closure::bind($this->fx, $this);
   }
} 

Modification of php is simple: 


https://github.com/php/php-src/pull/6063/files#diff-beea8c5a8ceb318220b34b73e4ecfc98R252


we simply pass the old object as 1 parameter. I belive, passing old
object have positives and no performance nor compatibility impact. All
other current solutions require an extra property and a lot of code, as
assigning in constructor is not enough (due serialization etc.), or it
is even impossible, if object was created using reflection without
constructor. 


With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

On 3 Sep 2020 18:00, Sara Golemon wrote:


On Thu, Sep 3, 2020 at 10:40 AM David Rodrigues 
wrote:


Now I rethinked about what I said. Really, maybe clone is not the best
option. So maybe we can just use a method that will clone and will have
access to both informations. But I don't know if it solves the original
message.

public function getUserCopy() {
$userCopy = clone $this;
$this->copies[] = $userCopy;

return $userCopy;
}

If your goal is to track copies, then a static makes much more sense.

class AllKnowing {
private static $copies = [];

public function __construct(...) {
self::$copies[] = $this;

}

public function __clone() {
self::$copies[] = $this;
}
}

-Sara

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Benas IML]

On Thu, Sep 3, 2020, 7:05 PM Sara Golemon  wrote:

> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues 
> wrote:
>
> > Do you think that it could be proxied? I mean, optimize foreach
> > (array_keys()...) syntax to not call array_keys() in fact, but a
> optimized
> > version of foreach to handle key only. I don't know it opcache could do
> > that, and if it already does.
> >
> >
> I wouldn't use the word "proxied", but yes. In my mind the compiler would
> see:
>
> foreach(\array_keys($arr) as $key) {
>
> and quietly transform that into:
>
> foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
> {
>
> Thus not iterating the array twice and creating a temporary array of key
> names.
>

Good idea; since I'm kind of bored, I'll try to implement a prototype
myself during my free time.

-Sara
>

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[Sara Golemon]

On Thu, Sep 3, 2020 at 11:03 AM David Rodrigues 
wrote:

> It was just an example to avoid modify how clone works, using existing
> features. :)


>

Right, but the question remains "Why would we want the original object
during a clone operation?".  No legitimate example of that has been
provided yet.

-Sara

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Sara Golemon]

On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues 
wrote:

> Do you think that it could be proxied? I mean, optimize foreach
> (array_keys()...) syntax to not call array_keys() in fact, but a optimized
> version of foreach to handle key only. I don't know it opcache could do
> that, and if it already does.
>
>
I wouldn't use the word "proxied", but yes. In my mind the compiler would
see:

foreach(\array_keys($arr) as $key) {

and quietly transform that into:

foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
{

Thus not iterating the array twice and creating a temporary array of key
names.

-Sara

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[David Rodrigues]

It was just an example to avoid modify how clone works, using existing
features. :)

Em qui, 3 de set de 2020 13:00, Sara Golemon  escreveu:

> On Thu, Sep 3, 2020 at 10:40 AM David Rodrigues 
> wrote:
>
>> Now I rethinked about what I said. Really, maybe clone is not the best
>> option. So maybe we can just use a method that will clone and will have
>> access to both informations. But I don't know if it solves the original
>> message.
>>
>> public function getUserCopy() {
>> $userCopy = clone $this;
>> $this->copies[] = $userCopy;
>>
>> return $userCopy;
>> }
>>
>>
> If your goal is to track copies, then a static makes much more sense.
>
> class AllKnowing {
> private static $copies = [];
>
> public function __construct(...) {
> self::$copies[] = $this;
> 
> }
>
> public function __clone() {
> self::$copies[] = $this;
>}
> }
>
> -Sara
>

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[Sara Golemon]

On Thu, Sep 3, 2020 at 10:40 AM David Rodrigues 
wrote:

> Now I rethinked about what I said. Really, maybe clone is not the best
> option. So maybe we can just use a method that will clone and will have
> access to both informations. But I don't know if it solves the original
> message.
>
> public function getUserCopy() {
> $userCopy = clone $this;
> $this->copies[] = $userCopy;
>
> return $userCopy;
> }
>
>
If your goal is to track copies, then a static makes much more sense.

class AllKnowing {
private static $copies = [];

public function __construct(...) {
self::$copies[] = $this;

}

public function __clone() {
self::$copies[] = $this;
   }
}

-Sara

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Marco Pivetta]

On Thu, Sep 3, 2020 at 5:35 PM David Rodrigues 
wrote:

> > Question for those who know about opcache optimizations: is it
> > feasible to avoid fetching the current value if the value is otherwise
> > unused and the variable-variable features are not used either?
>

TBH, this sounds like the best approach: optimizing the `foreach
(\array_keys($input) as $key) {` structure, when detected.

That would make it zero impact from an RFC/userland perspective, and the OP
by John is in fact about a performance concern, while we already have a
very expressive way to do key iteration.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[David Rodrigues]

Now I rethinked about what I said. Really, maybe clone is not the best
option. So maybe we can just use a method that will clone and will have
access to both informations. But I don't know if it solves the original
message.

public function getUserCopy() {
$userCopy = clone $this;
$this->copies[] = $userCopy;

return $userCopy;
}

Considering it, we have access to both now, with "write to source" support
with no additional feature need.

Em qui, 3 de set de 2020 11:21, Sara Golemon  escreveu:

> On Wed, Sep 2, 2020 at 2:11 PM David Rodrigues 
> wrote:
>
>> I understand... seems that `$this` is very confusing inside `__clone()`:
>> when writing, it writes to the clone, when reading it reads from original.
>>
>>
> That's not an accurate description of what happens today.
>
> $newObj = clone $oldObj;
> // 1. Engine creates a new instance of get_class($oldObj), without calling
> the constructor
> // 2. Engine copies all properties from the old object to the new object
> // 3. Engine invokes $newObj->__clone()
>   public function __clone() {
> // Userspace object handles any property specific re-initialization
> required.
> // $this always refers to the new object here.
>  }
>
> The question Niki asked is appropriate; What would one want to do to
> $oldObj here?
> If the goal is to read from the old object, then you have that already.
> The new object is a perfect copy, so read from that.
> If the goal is to write to the old object, then justify why you need to do
> so, because it's not a clone operation at that point.
>
> -Sara
>

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[David Rodrigues]

Do you think that it could be proxied? I mean, optimize foreach
(array_keys()...) syntax to not call array_keys() in fact, but a optimized
version of foreach to handle key only. I don't know it opcache could do
that, and if it already does.

Em qui, 3 de set de 2020 12:12, Levi Morrison via internals <
internals@lists.php.net> escreveu:

> On Thu, Sep 3, 2020 at 8:32 AM Sara Golemon  wrote:
> >
> > On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer 
> wrote:
> >
> > > > I currently use foreach (array_keys($array) as $key) { ... }
> > > >   to avoid complains from code analysers on unused var, is it slower?
> > >
> > > one argument brought forward initially (sorry, can't find the email
> > > right now) is the resource management: array_keys() has to create a
> copy
> > > [*] which might be an issue depending on the size of data.
> > >
> > >
> > While I like the idea of more explicit syntax to show intent over a mere
> > convention of $_ being an ignorable var, I do need to call out the
> foreach
> > (array_keys(...) argument as being a poor motivator.
> >
> > IF (and I heavily stress "if" here) this pattern is common among people
> > trying to show explicit intent and IF it represents a noticeable
> slowdown,
> > then the solution for it is for the engine to optimize around that by
> > transforming it during compile time.  That lets us fix all usages
> > instantaneously without user interaction, and more importantly it allows
> > users to focus on their code being readable (and thereby maintainable)
> > according to whatever coding standards they choose to apply.
> >
> > Again, that same argument is why I actually like the proposal overall.
> Not
> > because it's so much more performant, but because it empowers developers
> to
> > write code in a way that will be most readable and maintainable to them,
> > should they happen to just not like the $_ unused var pattern (which is a
> > legit thing to dislike).
> >
> > -Sara
>
> Question for those who know about opcache optimizations: is it
> feasible to avoid fetching the current value if the value is otherwise
> unused and the variable-variable features are not used either?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Levi Morrison via internals]

On Thu, Sep 3, 2020 at 8:32 AM Sara Golemon  wrote:
>
> On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer  wrote:
>
> > > I currently use foreach (array_keys($array) as $key) { ... }
> > >   to avoid complains from code analysers on unused var, is it slower?
> >
> > one argument brought forward initially (sorry, can't find the email
> > right now) is the resource management: array_keys() has to create a copy
> > [*] which might be an issue depending on the size of data.
> >
> >
> While I like the idea of more explicit syntax to show intent over a mere
> convention of $_ being an ignorable var, I do need to call out the foreach
> (array_keys(...) argument as being a poor motivator.
>
> IF (and I heavily stress "if" here) this pattern is common among people
> trying to show explicit intent and IF it represents a noticeable slowdown,
> then the solution for it is for the engine to optimize around that by
> transforming it during compile time.  That lets us fix all usages
> instantaneously without user interaction, and more importantly it allows
> users to focus on their code being readable (and thereby maintainable)
> according to whatever coding standards they choose to apply.
>
> Again, that same argument is why I actually like the proposal overall.  Not
> because it's so much more performant, but because it empowers developers to
> write code in a way that will be most readable and maintainable to them,
> should they happen to just not like the $_ unused var pattern (which is a
> legit thing to dislike).
>
> -Sara

Question for those who know about opcache optimizations: is it
feasible to avoid fetching the current value if the value is otherwise
unused and the variable-variable features are not used either?

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Dik Takken]

On 03-09-2020 15:07, Larry Garfield wrote:
> 
> I agree here.  _ is already a common pattern in other languages for a 
> placeholder ignored variable.  It's not a big jump for PHP static analyzers 
> to start ignoring unused $_ variables, and it requires no language changes or 
> formal standards.
> 

Technically that will work. However, this needs to rely on some
unwritten undocumented convention that all of the user community agrees
on and is aware of. Such a convention can be established and documented
of course, it worked for doc comments as well.

Apparently the PHPMD project considered a change to recognize $_ as an
ignored variable. It was declined:

https://github.com/phpmd/phpmd/issues/326

In stead, configuration was added to allow specifying a variable name
that is to be ignored. Still, every individual user needs to manually
configure it and pick a name for ignored variables.

For one use case, using $_ simply does not appear to be an option, while
using void is. This is the use case of ignoring an argument that is
passed to a function:

  function foo($_) {}

This can work but it changes the name of the parameter. That is not the
intent at all. It breaks in inheritance scenarios. When it is called and
the parameter name is specified as the parent defines it, a fatal error
results.

What I like about using void is that it has clear intent, it requires no
configuration of static analyzers and it provides a single syntax that
works for all use cases: foreach, destructuring and function parameters.

Regards,
Dik Takken

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

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[David Rodrigues]

Do you think that it could be proxied too? I mean, optimize foreach
(array_keys()...) syntax to not call array_keys() in fact, but a optimized
version of foreach to handle key only.

Em qui, 3 de set de 2020 11:36, Sara Golemon  escreveu:

> On Mon, Aug 31, 2020 at 6:56 PM tyson andre 
> wrote:
>
> > I've created an RFC for https://wiki.php.net/rfc/any_all_on_iterable
> >
> >
> I've probably reached this thread too late, but I'm going to throw out my
> old chestnut that these things don't belong in the engine. They belong in
> userspace.
>
> 1. Instant forward compatibility (any version can run `composer install`)
> 2. Instant bug fixes and improvements (no waiting for the next minor
> version of PHP)
> 3. Better visibility from the JIT (not having to cross userspace/internals
> border is good)
>
> And that's all I'm going to say because I'm pretty sure I've lost the
> argument long ago, but here's my any/all/none (and other) methods from
> years ago (IN USERSPACE!):
> https://github.com/phplang/generator/blob/master/src/iterable.php
>
> -Sara
>

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Sara Golemon]

On Mon, Aug 31, 2020 at 6:56 PM tyson andre 
wrote:

> I've created an RFC for https://wiki.php.net/rfc/any_all_on_iterable
>
>
I've probably reached this thread too late, but I'm going to throw out my
old chestnut that these things don't belong in the engine. They belong in
userspace.

1. Instant forward compatibility (any version can run `composer install`)
2. Instant bug fixes and improvements (no waiting for the next minor
version of PHP)
3. Better visibility from the JIT (not having to cross userspace/internals
border is good)

And that's all I'm going to say because I'm pretty sure I've lost the
argument long ago, but here's my any/all/none (and other) methods from
years ago (IN USERSPACE!):
https://github.com/phplang/generator/blob/master/src/iterable.php

-Sara

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Sara Golemon]

On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer  wrote:

> > I currently use foreach (array_keys($array) as $key) { ... }
> >   to avoid complains from code analysers on unused var, is it slower?
>
> one argument brought forward initially (sorry, can't find the email
> right now) is the resource management: array_keys() has to create a copy
> [*] which might be an issue depending on the size of data.
>
>
While I like the idea of more explicit syntax to show intent over a mere
convention of $_ being an ignorable var, I do need to call out the foreach
(array_keys(...) argument as being a poor motivator.

IF (and I heavily stress "if" here) this pattern is common among people
trying to show explicit intent and IF it represents a noticeable slowdown,
then the solution for it is for the engine to optimize around that by
transforming it during compile time.  That lets us fix all usages
instantaneously without user interaction, and more importantly it allows
users to focus on their code being readable (and thereby maintainable)
according to whatever coding standards they choose to apply.

Again, that same argument is why I actually like the proposal overall.  Not
because it's so much more performant, but because it empowers developers to
write code in a way that will be most readable and maintainable to them,
should they happen to just not like the $_ unused var pattern (which is a
legit thing to dislike).

-Sara

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[Sara Golemon]

On Wed, Sep 2, 2020 at 2:11 PM David Rodrigues 
wrote:

> I understand... seems that `$this` is very confusing inside `__clone()`:
> when writing, it writes to the clone, when reading it reads from original.
>
>
That's not an accurate description of what happens today.

$newObj = clone $oldObj;
// 1. Engine creates a new instance of get_class($oldObj), without calling
the constructor
// 2. Engine copies all properties from the old object to the new object
// 3. Engine invokes $newObj->__clone()
  public function __clone() {
// Userspace object handles any property specific re-initialization
required.
// $this always refers to the new object here.
 }

The question Niki asked is appropriate; What would one want to do to
$oldObj here?
If the goal is to read from the old object, then you have that already.
The new object is a perfect copy, so read from that.
If the goal is to write to the old object, then justify why you need to do
so, because it's not a clone operation at that point.

-Sara

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[David Rodrigues]

I don't see problem to allow modify the original object, once that you are
doing it by using a new argument, and not the $this itself.

Em qui, 3 de set de 2020 08:49, Pedro Magalhães  escreveu:

> On Wed, Sep 2, 2020 at 7:41 PM Michael Voříšek - ČVUT FEL <
> voris...@fel.cvut.cz> wrote:
>
> > do you have anything against updating PHP to pass "instance before
> > cloned" to any __clone call from php?
> >
>
> Yes, I think that allowing the original object to be modified by a cloning
> operation could be the cause for a lot of confusion. If we had a proper way
> to make it read-only I wouldn't mind, but as is, it doesn't sound like a
> good idea.
>

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Larry Garfield]

On Thu, Sep 3, 2020, at 3:25 AM, Nikita Popov wrote:
> On Thu, Sep 3, 2020 at 10:19 AM Dik Takken  wrote:
> 
> > On 03-09-2020 09:38, Brent Roose wrote:
> > > Hi all
> > >
> > > I want to point out the use-case when you're using CS tools, static
> > analysers and IDEs: they report unused variables as errors. There are ways
> > around those errors, but it's more convenient if there's language support.
> > I'd say that conceptually it's also more correct: if you're not using a
> > variable, it shouldn't be there.
> >
> > Exactly this.
> >
> > The intent of a particular language construct does not only need to be
> > clear to human readers but also to machines. More explicit intent leads
> > to stronger static code analysis tools, which helps us catch more bugs
> > earlier.
> >
> > Regards,
> > Dik Takken
> >
> 
> Static analysis tools don't need a language feature to support this. They
> can recognize the $_ pattern and not emit an unused variable warning for
> it. I'd suggest submitting a feature request.
> 
> Nikita

I agree here.  _ is already a common pattern in other languages for a 
placeholder ignored variable.  It's not a big jump for PHP static analyzers to 
start ignoring unused $_ variables, and it requires no language changes or 
formal standards.

I am skeptical of any performance difference, but from a reader-communication 
point of view a de facto convention of $_ == unused, and analyzers recognizing 
that, seems like the path of least resistance.

--Larry Garfield

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

[PHP-DEV] PHP 8.0.0 Beta 3 is ready for testing

[Gabriel Caruso]

PHP 8.0.0 Beta 3 has just been released and can be
downloaded from https://downloads.php.net/~carusogabriel

Or use the git tag: `php-8.0.0beta3`

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

Please test it carefully, and report any bugs in
the bug system: https://bugs.php.net

8.0.0 Release Candidate 1 should be expected in 2 weeks, i.e. on Sep 17,
2020.

Hash values and PGP signatures can be found below or at
https://gist.github.com/carusogabriel/e95befa31ef171ad911e882d1b8c9f05

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso

```
php-8.0.0beta3.tar.gz
SHA256 hash:
e7fa12065221d654d423e46d95155d2a0f20727e3a30d3355dc2a59793cf7906
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl9Og2AWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj9H+EADadPDzVHvgHguR02VA1ySG12m5
e8XkMDLpv4cfQEOwXqLi1JzcM5Qb6MktKNljXaLbZsmPtAVIhew3L7kdO7rZIjFi
CHNGyFoqndIZ3p0c731hl76azDikEC9PurJCHRbm30pyVquU61TqKt9SeBuesUXD
kaVHS+cLZDq97YxVo32mCBjB68rE6L4XwTDPouq5TgluxseckbYWIOJn9efr+Lwy
PYAogJ10onDdliw34rPlaWRxuOU218dxy9LcLG2iYNaqhes0bKbI2n6kNlWtDDaf
voTY+z2oiqbQbrQJYNz75IxmfyPDDTQyY8Z+2ZTaLbNH1fPTtq6O7Y7TGQHtC4nC
fFWqdFIeAad/iXuGOEVQVPd/ua/4ZQafODDaCDKAhzx5s/2bfmfap6WtG4LY67Xc
vE43YE6KCYRXVxxbHTA9h5EWuOBolaRwvolmcukdUfFAQVj+UFmje0dj2r2EBlQx
UOAWFYO47HZD5/AX6/UzTZUgsg68gmjwAftH1FKt1Cy9Q7wbV39/0xGg/QB9dw+y
cEw/je/9QDHHuIimTxP4e4WRxqZms5/pHkxxIVUf5qRJUFnUV4FczZlfNKNQdX4H
wij4RRzigsr9NAyfza3gjpYGfyAZFr/uYVYrg4BgMSs26moFMcnQYUI9wXiMICf0
bDXTD7JAuseDq5j2Ew==
=6FHi
-END PGP SIGNATURE-

php-8.0.0beta3.tar.bz2
SHA256 hash:
88da661bf24d14ca17fc21822433cfa95d6540c00e57d6a56def348305121250
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl9Og2EWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj+jrD/9lWpkLrAgBfSELvA3FhqaYhgtm
+LatgQ7yl29ajQSbke/CqqilaN5y9VNJwzP/VoCGs64LIe4pI76dJu1WVY7GQ7Vo
vPrPKgyJLzGKllKC/ayBPP44cOAWu3+ZrCkO/E6cB2V9mtjhVUj21TRhfigVY4nP
CsG17FijjcVvIvGjcwaHN/78kP4WZbOEFW2jNRrJXT/JYbARFX4z8mabzJML3ZZo
XI5UlCsRLuIMHtJ2eb9oS/ZQ0UiiM40wiBEoK0iijZl3Xxld0AoLEEqwjhHJTfiG
v1IFSjIezscctQphhtlvYWuLiLtVqYtlGTlQIr8DG9rfFJe44+TeZ0Sgl1nSbWtH
t6xA8NUUK4uSppM6/sYlhgGly3ooXd93pfJpMo3x3/ZRbDBMqmrpzTyo3wfbk6eN
pu/iO4P/e19ZilFvvnvlEDwg66XnMD6XScWEKPN/IsYMKXJOHVVs0MVT4jCOXA7o
MInti7cWK6OxJ97IF8Fuw+dgYaPoCaUcIqojBIbt/FlYJWf/G9BF0++/4KuBM9OO
oPWy4GOc3TvYpxRRnxGn7Ncv2FP3C9Jd11bI0YtNjgqW6XgVWauQ/gVwA/38U3hl
6PenNTsEjAJ4arzwoDiEI7HeVtiQ31DgnxHtAjhD/2cjtM92X4v3J58fYrQSHygm
eGuvnRQ4qVMHzmjh2g==
=3vBe
-END PGP SIGNATURE-

php-8.0.0beta3.tar.xz
SHA256 hash:
a52b4e07e14a3986482e08fdd82df027acc46acaffb6409bef8290dd218fbcec
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl9Og2EWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj11kD/wPC2W3wV1+1N3d2yum9BWdFPFI
YPeybad+WG6UuD1XeQLg00FIiWppPWcEqhOeCm5X4FJ8ak9R5Tu7O5v3dR7cIeSp
l5dMC4N2NuPYRHfZLLElhwK7WiA2YByX/VBZF8pggyEOE18MuzkvwYIgf19BDUu3
OX8mDuBGc9jugvBZ9QahyM1VyxcH0GXbQ1XvEyFLtdaBbHlmWexl/8DM1zmKDvCN
6PSgU0wfhusZFeUOz1k9/NnygbXE6TKyGmXheEXdiog1ZCn5MU+z7iUpOatZIhtF
RvyPyUEBQ75amOJdyN1n3SDwfyB/ZcUtYtFtEfQwAgKIlbXnn4Ae0L3/q3m/csWL
kNlINyC/MsSN/TYgSflhb85rp3oxPr+Hex9D6O4PzoSA3DAq5m4LMvgQLFfY2H8g
BFtSfujEvBlMwJrmYjlyJooDwqcFcxxDPfdpx/j904hLuGNR18mkoK0I/ZGC9F87
YOchWzsuePHPq9Uj0pgt3H5wuzHQdAraCAsRY2fgA0bHPZAbXXbwBq9CCj/iBpp1
WwbpSNHi3ARszlhfxJBDTX85Qqioo56ELR2uhsS0R4h0oEeGe7gTym+0JA8T38qS
RopxjoKkXctsPO6r3xbJPuZ240VLD5iRQUSkfNFjZDaqsKx5RF0SnvEsUIk5Vmdz
LPWersAubI+Z84XYkg==
=tWYk
-END PGP SIGNATURE-
```

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Nikita Popov]

On Wed, Sep 2, 2020 at 1:54 AM tyson andre 
wrote:

> Hi Lynn and Nikita,
>
> > To be in line with naming conventions, I would suggest calling these
> > iter_any() and iter_all(), using iter_* as the prefix for our future
> > additions to the "functions that work on arbitrary iterables" space.
> > iterable_any() and iterable_all() would work as well, though are
> > unnecessarily verbose.
>
> I'd also feel like iter_any() could get confused with iterator_apply() for
> Traversable
> in terms of whether it's shorthand for iterator or iterable when learning
> the language.
>
> There's been more discussion than I expected on this, arguments for both
> options, and I'm not sure what the overall sentiment of voters is.
> I was considering creating a straw poll on the wiki with 2 questions to
> guide the final version of the RFC/PR:
>
> 1. Name choice (iterator_all(), iter_all(), or all(), or no interest in
> adding the functionality)
> 2. Interest in future RFCs to extend support to keys and entries
>
> Thanks,
> - Tyson


The main thing I'm concerned about is that once we start extending this
area (I assume that any & all are not going to be the last additions in
this space) we will quickly run into function names that are either too
generic or outright collide. For example, what if we want to add an
iterator-based version of range()? Do we *really* want to be forced to pull
a Python and call it xrange()? That's about as good as real_range()...

As such, I think it's important to prefix these *somehow*, though I don't
care strongly how. Could be iter_all() or iterable_all(). We might even
make it iterator_all() if we also adjust other existing iterator_*
functions to accept iterables. I'd also be happy with iter\all() or
iterable\all(), but that gets us back into namespacing discussions :)

Regards,
Nikita

RE: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[CHU Zhaowei]

Regarding the unused variable, I think OPCache should be able to identify and 
eliminate it. I don't think it's necessary to add a new syntax here.

Array destructuring sounds like a similar case to me. If you don't like [, , 
$v] =$arr, you can use [$_, $_, $v]=$arr instead.

Regards,
CHU Zhaowei

-Original Message-
From: Dik Takken  
Sent: Thursday, September 3, 2020 3:31 AM
To: Nikita Popov ; Mike Schinkel 
Cc: John Bafford ; PHP internals 
Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

On 02-09-2020 19:13, Nikita Popov wrote:
> Just like the first time this was discussed, I don't think this RFC 
> makes a sufficient case on why we need explicit syntax for this. Just 
> ignoring the value is an existing pattern that works across all PHP versions:
> 
> foreach ($iterable as $key => $_) { ... }

While this works fine, it does introduce an unused variable. Code inspection 
currently complains about that, and for good reason, which is annoying.

Even if we decide that it is not worth the trouble for foreach loops, there are 
other cases where this new syntax can work well. Array destructuring has 
already been mentioned.

Another case is the one where a function intentionally does not use one of the 
arguments passed to it. This happens easily when using callbacks or when 
implementing interfaces. A function declaration could look like
this:

  function foo($arg, void) {}

This indicates that the second parameter is intentionally left unused.

Perhaps it is a good idea to generalize the RFC to the general concept of 
"using void to intentionally ignore a variable". Maybe pick just one use case 
for actual implementation and extend later using followup RFCs.

Regards,
Dik Takken

--
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] Pass source object to clone like __clone($origThis)

[Pedro Magalhães]

On Wed, Sep 2, 2020 at 7:41 PM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:

> do you have anything against updating PHP to pass "instance before
> cloned" to any __clone call from php?
>

Yes, I think that allowing the original object to be modified by a cloning
operation could be the cause for a lot of confusion. If we had a proper way
to make it read-only I wouldn't mind, but as is, it doesn't sound like a
good idea.

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

[Nikita Popov]

On Wed, Sep 2, 2020 at 8:42 PM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:

> Hi, please look at
>
> https://stackoverflow.com/questions/63675888/get-original-source-instance-in-clone
>
>
> do you have anything against updating PHP to pass "instance before
> cloned" to any __clone call from php?
>
> no BC - user may accept this extra argument or declare function
> __clone() without any param like now
>

Could you please provide some more information on what the intended
use-case is?

I'm not opposed to this change, but I also don't understand why it is
needed.

Regards,
Nikita

[PHP-DEV] PHP 7.4.10 Released!

[Derick Rethans]

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

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

For source downloads of PHP 7.4.10 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.10.tar.gz
SHA256 hash: e720f1286f895ca37f1c75a2ca338ad2f2456664d7097298167181b25b212feb
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl9OU74ACgkQkQ3rRvU+
oxKnTg/9EYFnzv3ENm2IdZGDuaCxVQ09WatsRUCaCwpbgzcz93G1ouasfnmjJ/zJ
DW0TGJofGoKoTRSr46zM4MtalobzRGIjRS+4voV8TKGQsKuR5j54I3jwkASb+8Ar
3LJX6YOYbP0ZuaZ1br5Ee2RC4rPhDVOLr2vjaRz24SE3uIlXogNBfheTvpY8np1i
k0th7tg0a1y06JyzqTz0x983vSwQPtPGrdIX03cL9VYtpF/C6F8Lno6XSwhNs+Qs
qq3FO5j1FkLs5DqAoNpGcuIVanGhYqjBBA851OY0l5SyzDNxxaPT62qg5k4BqIck
/GkJRkfJ8sT/9b2hrMz1LO+iWli9JWstiNwGqvcIruOmTb1Ca3rP5TZkb08yTq8Z
2b1YUNQb34QizrjHxo9hkaVd8zAPdQMiy9WTVpzRb4w9K0SD1ipNJF5lJqnU7sIj
n2n0fzmU0JIkLTDeDXC+JrW0rpLbCDCZ3cD7VYsSJRWeMB3YGSHEYC84te2qwvbw
5Wb0nHMtve7PQB2emwQaaei5VTLPmo90j8t22R28yT3xYGfDw6IMxovs+L0kkqch
45saXPi3GPg8fCDUwoRX2VM3VNAmlq2+NFUZf0VUXusUyTin97qEVkXOcT4R/tQ/
Y+oCNRWdReXPFI4HFFCRHts/+ZsFaCPQU/npiUHR3a5hmuNUU+4=
=gnGa
-END PGP SIGNATURE-

php-7.4.10.tar.bz2
SHA256 hash: e90bfc9ed98d24e53b51ffd4eb636cf5cd9d71ed7c6f8e4b6e9981e9882174e7
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl9OU8IACgkQkQ3rRvU+
oxIUyA//TmgEA/vO+Crnv04M1Ty0iBidfHK5UnIfM+tusqtyj88PAFOkbkSZzvym
JM/m+TuyMKLWyirKfI0MFhSvxpXFPfBCbS6GMnrL4uVlwf3jxyHmQoQI0c39bPcV
xx1LNYeLesbu8qtPYBDzP1GIW8PRM3Efmu+H7/Sb1SjT4ngHcpdlzudqqF3y+I8Y
ZmgwDqC4XThglJoO84Z7ahvxgxqarQ8GX2VGWnnSKoPu6RB1ZZkXo2GP/MIf3xhv
kBcTk1Km3LbSsPMWfSSZ7xFzTP2cqM2JKVI7g14YNXq92cfvZJyhHF4KOKhGoqOP
ldoK/zwMLKJMymOHo1SWRyQKzWipIhsdC46BBOWoTTeKMPidSevY3ZEuyiVPFZIe
5RkiCFJrNS7UbvT8wvaJigHRuxDxXZmoZ1n3L0gcmxpQlJ48zlsVvjn6litOI6ge
VQl2M8wMITcCC9e++iKhMky/PdTEHvp5qSrP0FlrRHnlJ3hqVpQIJCAieg0Qlgf4
lMdSQ6aw+xRmWMx1mkLA+OGYmWdfAPEMl3JOfjG/cTPcxP+8rW1dANny+mbe0G/k
IPlDtsl9lNxU93/66g9+dkxA9985cG1EyXEy848RXtamWEg2zGi6GADqvfTigCrB
sObn0+la3iOb7Sq4XLCY9KkYXpqAb0qfRw9+oE7cgI4z5+Ion3E=
=a9kp
-END PGP SIGNATURE-

php-7.4.10.tar.xz
SHA256 hash: c2d90b00b14284588a787b100dee54c2400e7db995b457864d66f00ad64fb010
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl9OU8MACgkQkQ3rRvU+
oxLGbw//dWhAOQyrzCXb4Xcbm83IS1n457ZzwOgkFANcVL8oT/3AgXJ0fiBfgYVI
DwTOb781s7rTnV6isRgQi1nRX7PC3Bg7pr2wjINQx8zQQmYl3xwlvdS+Be2ADIAB
4UwCRJPT22YyqJL0YO/z4MhfRDqLy6DrY8SnorXLkPsAzlfECz6QSWNz1VUS2l0G
ozfay1ENTjFsZnxXHMIpcZCN0UENIYdy8cZe7K8b9HFdCq8n/cgVqdYfNOZsvFPG
BsygoZZ0nvVvru5Ot8oa4g4/IU+3jDpnFvV80glO8Az4601au96uwIzx2sD7ALm9
uJt0Uie8baV85fA6kBm5jy3xHj63xpqIRpRjTqInIwUvFR6fFYsVA8YZLbubq0Jz
mdZCx3g430qz8kMmSC0i4JEX8ZeIQEN0x1Bl2VgoYgeN4PYKBBTu+vy6EVTtLDIB
yAdwtlI5y8qHnVzEvXWpyUAeXFzVAsp+TbJgbFPOCbdbNjM2SKKSZDVUZC+XtCRl
MvDNXwS3itX2KjYbRliLZl/I5y9Me+uyuaZKlP4DDefvYoxvC+5E1yp/fDQH1dDa
wQqUFku6+was4zs251XrSilxf2Vt1rCYtBTLTOpeDY6NpviJ0zmjGbZm5C6UnmKG
aZk+X2zEDfcvQ2kvFGBYUJLwN1HCLxIXWRTSsEjXKZdXdikZLYk=
=vybB
-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

[PHP-DEV] PHP 7.3.22 Released!

[Christoph M. Becker]

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

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

For source downloads of PHP 7.3.22 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.22.tar.bz2
SHA256 hash:
c790b8172520b2ff773d6cf80774ea0a678a2f16e8ee6b11d68802094448689e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl9OGrMMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2vLwQAIr26thaKdmq7D8MZLHWAQCB7Wwd1s08nVlssFj1
DKU6t5bEmB48nAqe8fOA/jQSnR8tZRviBMPMFwsDxp6KlOAJtJ06xA3tGg8Er9G/
BapEf5KGgOfXSgrwH9ZbmiLCUsB8Gw5q70NU+D8XPd3M78HlXE70Rv89V27i9Q1a
F8kQ3WMAAGmb23XuHd8RXVr2jsLnEAPDj3G3Q9BOfeYFuoguFubb1o4PgYzEj6LX
0+aoutgwJGuXw6bp9rPOGdFNX1gmsltovuYEee96FVvsIH7tbBjbd7z+fNZpmhs3
w8N5HNNaRUZBB/RopUklMmjv1G0TxavfJ4domy3Qd/DtVWVT5gdpuQDgwgMZUH5c
Gv/zBrrebOquIR+gnYu/o7E6E2yQ1kIpm+XdFxmcYnEEze3IRJpSqYmaD79v/tKD
Ais2SWXvaGrugSFlPzGbVJuDNKj2wTdD8uag549fJnTNIrSFlOBnwkOUculgesPf
Jaq5k1isnUp451yzljWpPiup50g1xPa1XEJ5F4xLEpMYWSocanfZurjZIv8btjSE
oopez94judITEWfeEbtTwtITCcDY4usvjMCl1JAsR62sRJaHdRmnG0inH+YLXvOj
TxzQzAiHMegPukAlAqniJ+QKosNSg7pX9CWJwpPcQMN96IwDitripqu06JQOE1uo
JFGT
=TJ4u
-END PGP SIGNATURE-


php-7.3.22.tar.gz
SHA256 hash:
759426cb4054e3f23316c39710faff0bb8063fd0ea50fc2c5efa590429af1a22
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl9OGrkMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2nnIP/Rsg0X33u0wIzc2WRq67auIuniZBDPWPsD+iVv+F
lMlRH4Q2WV2HXOuEuRji2js0p9dAbhna5SInKqxCor8kWNyQ71bHLJ/tT4tby8sE
fwbgUvOWKt/JeiYCSsn/AAVy8QuJzwPYxDKrrxMmPhBhOU2DjkhjMQuLIR8M1QTg
n1yA2XN7mdLEaj44suktXskSu/SyFGcSwWPmXW+NhdfuTboPFBOTAKWk3af7+9eo
gr/pxTVR3egnQH3+LYBNjDUaTWJQ/rNGFjrfmgy6I5d1NdiSdUN8PgNYVi4gzqM6
4d0idwqNpIXVA1pQt5vZFiPIKnFAEZZy2Awgh6U7oU8tqxqyZ/CEgMv512hSikOq
lJLoBWEHZBsEtJ+i81tCFdzids7d8f8FPWpyjb4UUntCeh4RtKr+Ur0PIxeWpA2T
vSf7mH1d/SLGurgTudNR96T/I1tFi8qpqRGCegfGLLOk5nqiV/e0hpw7w2I1XHaw
LMCdKlJ3/40onznlSp57z0Oq00A2ASuktCaEHvAAoKDcG3dtr/xInFEgBR646sso
o5+GzRsS1s69Na0617tIc3MbdhUOu4GTaEaoPyIjGWIp4DUAw19gvvOP3xyh9S25
lHEqu5ehqBzU5wMSAsGJf2RAyX4OhnmjaBcgK1UFDomdOEHMF3caBXbxJEkhGaNK
Jg9D
=xhuX
-END PGP SIGNATURE-


php-7.3.22.tar.xz
SHA256 hash:
0e66606d3bdab5c2ae3f778136bfe8788e574913a3d8138695e54d98562f1fb5
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl9OGrkMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2cD4P+QG/cbbXRlKVZ4VsqXdgaZbBLH4XV72kkrOMq8VG
9ioOIClKNq9y932vK8PGUCmodZeWbrQ+EUJTpj5aP+g+jb7nl415wDfu613FWrZf
TzEdQAROMY7TwkmleK1UcHgla9a0aASsgU5xEf1JJftpuN1zhh0kTUPij6e2HEbp
+C92hs2bCSllLznSgl/lsPIEoSlwM6hH3xhyJp+UOYr55DWic9t23NpIgzc5s6Fd
1RFcuFEzo/zZ89zcV7JvzIzw5oPDNq17iVeRUKf92P464QYZG4OtZsBuAIGr/Qpl
nob2XkFMTZrxGvgAL0lqWQhw6BoJhNiMYIq0I2P0P40hRkSU7DX6avNOeHdXGhOO
uD8LKWOh+tpz4NRrIz5PyyajWOAvuWzCW7U5C8dE7bvyjZYVgBahcZscO3+T81qm
mRwf6DWNDu8GNvAxe9LqYjBl2tY7WC90L9G3ky7RmlyspUbmSiyiJrZ4/N6J12rr
VIq4/3DH0zqqCMMowFbdE6DF+rPtidEqgGBlCLgu8gXjqmNEo2GrbV/BGOmxax0K
PIgMdH1tLjmh8HcXYnjhq65o7PDzEE4Y+7LemZZbHL+4wX0y57skVyFgWzR9AzAA
8DEwzFcSSw5KQQIDJP1ECqtjg0FYlqMAmW8tJHGg2OV6BtvzeeqOndktdJ3mVyOq
LcTB
=bUDc
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Markus Fischer]

Hi,

On 03.09.20 09:58, Côme Chilliet wrote:


 foreach ($iterable as $key => $_) { ... }


I currently use foreach (array_keys($array) as $key) { ... }
  to avoid complains from code analysers on unused var, is it slower?


one argument brought forward initially (sorry, can't find the email 
right now) is the resource management: array_keys() has to create a copy 
[*] which might be an issue depending on the size of data.


- Markus

[*] I now about shallow-copy, I'm just trying to cite the initial 
argument as best as I can :)


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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[kontakt]

Von meinem iPhone gesendet

> Am 03.09.2020 um 09:39 schrieb Brent Roose :
> 
> Hi all
> 
> I want to point out the use-case when you're using CS tools, static analysers 
> and IDEs: they report unused variables as errors. There are ways around those 
> errors, but it's more convenient if there's language support. I'd say that 
> conceptually it's also more correct: if you're not using a variable, it 
> shouldn't be there.
> 

These tools all work with documentation conventions already, it would be much 
easier they standardise on $_ to allow being unused instead of changing the 
language.


> As some of you have shown, there are ways achieve the same result without 
> adding new syntax. Just like we didn't need short closures and keep using the 
> normal closure syntax, like we could write if statements and didn't need the 
> nullsafe operator, like we didn't need named arguments or constructor 
> property promotion. I think the past years of PHP devlopment have shown that 
> the majority likes convenient langague syntax and constructs, not because 
> it's absolutely necessary, but because it's just a little more clean, a 
> little less verbose, a bit more convenient.
> 
> PHP has been maturing over the last years, which means there's room, and 
> need, for things that aren't strictly necessary.
> 
> Kind regards
> Brent
> 
>> On 3 Sep 2020, at 09:18, Stanislav Malyshev  wrote:
>> 
>> Hi!
>> 
>>> If it adds a micro-optimization, great, but allowing a developer to
>>> explicitly signal intent is the primary argument for adding void.
>>> IMO.
>> 
>> You can signal intent by using $_ or $dummy or whatever. You don't need
>> new language construct each time for each way of using or not using a
>> variable.
>> 
>> -- 
>> Stas Malyshev
>> smalys...@gmail.com
>> 
>> -- 
>> 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] Draft RFC: foreach iteration of keys without values

[Nikita Popov]

On Thu, Sep 3, 2020 at 10:19 AM Dik Takken  wrote:

> On 03-09-2020 09:38, Brent Roose wrote:
> > Hi all
> >
> > I want to point out the use-case when you're using CS tools, static
> analysers and IDEs: they report unused variables as errors. There are ways
> around those errors, but it's more convenient if there's language support.
> I'd say that conceptually it's also more correct: if you're not using a
> variable, it shouldn't be there.
>
> Exactly this.
>
> The intent of a particular language construct does not only need to be
> clear to human readers but also to machines. More explicit intent leads
> to stronger static code analysis tools, which helps us catch more bugs
> earlier.
>
> Regards,
> Dik Takken
>

Static analysis tools don't need a language feature to support this. They
can recognize the $_ pattern and not emit an unused variable warning for
it. I'd suggest submitting a feature request.

Nikita

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Dik Takken]

On 03-09-2020 09:38, Brent Roose wrote:
> Hi all
> 
> I want to point out the use-case when you're using CS tools, static analysers 
> and IDEs: they report unused variables as errors. There are ways around those 
> errors, but it's more convenient if there's language support. I'd say that 
> conceptually it's also more correct: if you're not using a variable, it 
> shouldn't be there.

Exactly this.

The intent of a particular language construct does not only need to be
clear to human readers but also to machines. More explicit intent leads
to stronger static code analysis tools, which helps us catch more bugs
earlier.

Regards,
Dik Takken

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Côme Chilliet]

Le Wed, 2 Sep 2020 19:13:20 +0200,
Nikita Popov  a écrit :
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
> 
> foreach ($iterable as $key => $_) { ... }

I currently use foreach (array_keys($array) as $key) { ... }
 to avoid complains from code analysers on unused var, is it slower?
One obvious pro of having a dedicated syntax is not having to ask those
 questions to ourselves while coding.

> Iterating over just the keys is not a super common pattern and we already
> have a reasonable way to do it (that is imho just as clear, and actually
> more concise than the proposed "null" variant). The only potential
> advantage to a dedicated syntax that I see is that there could be iterators
> that can cheaply produce keys, but have expensive to produce values. That
> seems like an edge case of an edge case though, and is a situation where
> manually calling ->key() would be justifiable.

In our code base I thinks it is quite common.
grepping on "foreach (array_keys" gives me 51 cases, while grepping "foreach ("
 gives me 1153, so that’s 4% of our foreach uses.

Côme

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Brent Roose]

Hi all

I want to point out the use-case when you're using CS tools, static analysers 
and IDEs: they report unused variables as errors. There are ways around those 
errors, but it's more convenient if there's language support. I'd say that 
conceptually it's also more correct: if you're not using a variable, it 
shouldn't be there.

As some of you have shown, there are ways achieve the same result without 
adding new syntax. Just like we didn't need short closures and keep using the 
normal closure syntax, like we could write if statements and didn't need the 
nullsafe operator, like we didn't need named arguments or constructor property 
promotion. I think the past years of PHP devlopment have shown that the 
majority likes convenient langague syntax and constructs, not because it's 
absolutely necessary, but because it's just a little more clean, a little less 
verbose, a bit more convenient.

PHP has been maturing over the last years, which means there's room, and need, 
for things that aren't strictly necessary.

Kind regards
Brent

> On 3 Sep 2020, at 09:18, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> If it adds a micro-optimization, great, but allowing a developer to
>> explicitly signal intent is the primary argument for adding void.
>> IMO.
> 
> You can signal intent by using $_ or $dummy or whatever. You don't need
> new language construct each time for each way of using or not using a
> variable.
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Riikka Kalliomäki]

> Iterating over just the keys is not a super common pattern and we already
have a reasonable way to do it (that is imho just as clear, and actually
more concise than the proposed "null" variant).

The reason I in my previous message suggested the engine optimization
for the "foreach (array_keys($array) as $val)", is because I feel that
iterating over the keys of arrays is, in my experience, a relatively
common pattern. The reason is that array keys are occasionally used
for storing things like strings or numbers, especially when you need a
simple to implement unique list. On the other hand, I have never had
the need to specifically iterate over the keys of an iterator.

Additionally, I feel that there are other advantages to (at least)
implementing that optimization:

- The engine itself does not necessarily need to handle it differently
from normal foreach. Maybe the engine could, in fact, treat it just
like "foreach ($array as $val => $_)"
- This is a pattern that I already see happening a lot in existing
code, so optimizing this case would give some benefits to existing
implementation
- This would not require any changes to existing php syntax
- Should special syntax be introduced later, this case could be
converted into that syntax at that point

While the disadvantage of doing just this is that you can't easily
apply it to iterators, the thing is that iterators are already calling
other functions. The point here is to apply additional context
awareness to avoid unnecessary execution on existing language
constructs. I would see this more akin to dead code optimization than
a language feature.

On Wed, Sep 2, 2020 at 8:14 PM Nikita Popov  wrote:
>
> On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel  wrote:
>
> > This is a new thread for John Bafford's RFC which he mentioned on another
> > thread, see below:
> >
> > https://wiki.php.net/rfc/foreach_void <
> > https://wiki.php.net/rfc/foreach_void>
> >
>
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
>
> foreach ($iterable as $key => $_) { ... }
>
> Introducing special syntax for this has costs, both in terms of language
> complexity and in terms of implementation complexity. For example,
> implementing this feature will make foreach (whether or not the value is
> ignored) marginally slower, because we will have to explicitly distinguish
> this case. (Or alternatively, we'd have to specialize and increase VM code
> size -- it's not free in any case.)
>
> Iterating over just the keys is not a super common pattern and we already
> have a reasonable way to do it (that is imho just as clear, and actually
> more concise than the proposed "null" variant). The only potential
> advantage to a dedicated syntax that I see is that there could be iterators
> that can cheaply produce keys, but have expensive to produce values. That
> seems like an edge case of an edge case though, and is a situation where
> manually calling ->key() would be justifiable.
>
> Regards,
> Nikita
>
> > On Aug 31, 2020, at 5:50 PM, John Bafford  wrote:
> > >
> > > Hi Riikka,
> > >
> > >> On Aug 31, 2020, at 14:13, Riikka Kalliomäki <
> > riikka.kalliom...@riimu.net> wrote:
> > >>
> > >> A common pattern that I've seen that could dearly use PHP internal
> > >> optimization, if possible, would be:
> > >>
> > >> foreach (array_keys($array) as $key) {
> > >> }
> > >
> > > I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch (
> > https://github.com/jbafford/php-src/tree/foreachvoid against php 7.0, I
> > think) that helps with this, by allowing the following syntax:
> > >
> > >   foreach($iterable as $key => void) { ... }
> > >
> > > This would iterate over the keys of the iterable, and does not retrieve
> > the values at all.
> > >
> > > In theory, this should be a general performance win any time one needs
> > to iterate over only the keys of an iterable, because it does not require
> > the use of an O(n) iteration and building of the array that array_keys()
> > would, plus it works on non-array types (such as generators or iterators).
> > It also is more performant than foreach($iterable as $key => $_) {},
> > because it omits the opcode that instructs the engine to retrieve the
> > value. (Presumably, a future direction could include using this request to
> > inform generators or iterators to only return keys, and not values, which
> > could further improve performance, especially if value generation is
> > expensive. But that is out of scope for this RFC.)
> > >
> > > If this is something we'd like for PHP 8.1 and there are no major
> > objections to the idea, then after 8.0 is released, I can move the RFC out
> > of Draft and into Under Discussion, and presuming a vote passes, I'll
> > update the patch as necessary to work against 8.0. But my time is limited
> > and I'm not willing to put further 

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Stanislav Malyshev]

Hi!

> If it adds a micro-optimization, great, but allowing a developer to
> explicitly signal intent is the primary argument for adding void.
> IMO.

You can signal intent by using $_ or $dummy or whatever. You don't need
new language construct each time for each way of using or not using a
variable.

-- 
Stas Malyshev
smalys...@gmail.com

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