> 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
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
>
> 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
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
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
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,
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
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
-
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
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
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
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
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.
>
>
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
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;
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
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
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.
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:
>
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
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
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;
//
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
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
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
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.
> >
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
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
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
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
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
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
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
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
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
>
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
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
> 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
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
39 matches
Mail list logo
