This would be a fantastic addition, and it would also alleviate an issue in
static analysis land where it's very tricky (in the general case) to verify
exactly what implications successfully completing a given foreach loop has
on the array being iterated over (e.g.
https://github.com/vimeo/psalm/is
Hi Levi Morrison,
> I was actually working on this sort of thing recently. _Technically_,
> you can support `all`, `any`, and `first` by using a single function:
>
> function find_first(iterable $of, callable($value, $key): bool
$thatSatistifes): Iterator
>
> It converts the $iterable into a
Hi internals,
I've created an RFC for https://wiki.php.net/rfc/any_all_on_iterable
This was proposed 2 days ago in https://externals.io/message/111711 with some
interest
("Proposal: Adding functions any(iterable $input, ?callable $cb = null, int
$use_flags=0) and all(...)")
- The $use_flags pa
Hi Riikka Kalliomäki,
> Another similar problem with creating array copies is the detection of
> "indexed" arrays (as opposed to associative arrays). Particularly when
> dealing with JSON, it's a common need to detect if an array has keys
> from 0 to n-1 and in that order. My understanding is that
Hi Riikka,
> On Aug 31, 2020, at 14:13, Riikka Kalliomäki
> 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
I would highly prefer php optimalization for it. ArrayKeysIterator can
not even used if the input is iterable instead of pure array.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 31 Aug 2020 23:31, Max Semenik wrote:
On Mon, Aug 31, 2020 at 11:53 PM
On Mon, Aug 31, 2020 at 11:53 PM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> Optimizing foreach (array_keys($arr) as $k) is very important, not only
> because of memory, but because of speed when not all elements needs to
> be iterated, like:
>
> foreach (array_keys($arr) as $k) {
ok, that seems to be working now as well.
Optimizing foreach (array_keys($arr) as $k) is very important, not only
because of memory, but because of speed when not all elements needs to
be iterated, like:
foreach (array_keys($arr) as $k) {
if ($k some condition) {
break;
}
}
please, can someone send a PR for this?
That is great news, but when will social login functionality be back online?
Regards
mega6382
On Tue, Sep 1, 2020 at 1:47 AM Sergey Panteleev
wrote:
> Hi,
>
> the editor has been restored, you can use https://edit.php.net
>
> wbr,
> Sergey Panteleev
>
>
Hi,
the editor has been restored, you can use https://edit.php.net
wbr,
Sergey Panteleev
On 31 Aug 2020, 23:44 +0300, Haseeb A. Basil , wrote:
>
> https://edit-new.php.net/ is also down, what is the plan here? Is something
> going on? Is there some work in progress to create a new platform or
>
Hi,
https://edit-new.php.net/ is also down, what is the plan here? Is something
going on? Is there some work in progress to create a new platform or
something?
NB: You have SplFixedArray which can cover some use-cases.
On Mon, 31 Aug 2020, 20:48 Markus Fischer, wrote:
> On 31.08.20 20:13, Riikka Kalliomäki wrote:
> > Another similar problem with creating array copies is the detection of
> > "indexed" arrays (as opposed to associative arrays).
>
> I'm l
On 31.08.20 20:13, Riikka Kalliomäki wrote:
Another similar problem with creating array copies is the detection of
"indexed" arrays (as opposed to associative arrays).
I'm looking forward to an answer from someone proficient in this area
because _I think_ the engine _internally_ keeps track of
Hello,
For the past couple years I've been working with a PHP code base that
at times deals with quite large payloads memory wise. This has made me
pay more attention to some array operations in PHP that are rather
frustrating to deal with in userland PHP, but could perhaps be
optimized more in PH
> I wouldn't vote against a flag on array_filter(), because doing the quick
and easy thing is very much in PHP's DNA, but I think we can cover a lot
more ground with a more general purpose solution that leaves userspace to
deal with bigger problems.
I totally agree with you.
Atenciosamente,
David
On Mon, Aug 31, 2020 at 10:35 AM David Rodrigues
wrote:
>> It should be possible for the engine (at some layer) to look at that
closure
>> and see that it's just negating some proxied call and elide setting up
the
>> intermediate frame. Microoptimizations SHOULD be the engine's job, not
userspace
> Just to be clear, I think you're referring to "compared to the case of a
bare string callable", e.g.: array_filter($arr, 'is_numeric') vs.
array_filter($arr, fn($x) => !is_numeric($x));
Yes, because I can optimize it when array_filter() is "positive-only", but
I can't when I need to be "negati
On Mon, Aug 31, 2020 at 9:41 AM David Rodrigues
wrote:
> > I agree with Larry that userland implementation is trivial enough that it
> > doesn't really need to be implemented in core. It's just syntactic sugar
> > that's probably more trouble than it's worth. That being said, I'm by
> far
> > an
> The original poster had a typo, I think, and meant array_reject not
> array_reverse. He basically implemented the solution that Larry was
> referring to, before Larry referred to it.
Yes! It means to be "array_reject()" instead of "array_reverse()". And my
syntax is wrong too, actually it should
On Mon, Aug 31, 2020 at 9:52 AM Josh Bruce wrote:
> Just to confirm
>
> array_filter(“!is_int”, $collection)
>
> Would result in a collection of only non-integers??
>
>
No, you'd have to put it in a closure
The original poster had a typo, I think, and meant array_reject not
array_reverse. He bas
Just to confirm
array_filter(“!is_int”, $collection)
Would result in a collection of only non-integers??
I do think there’s something to be said for the communication of intent without
syntax.
array_without or array_reject reads easier to me than making sure to watch for
the bang.
Cheers,
Jo
On 29.08.2020 at 09:30, Matteo Beccati wrote:
> Hi Christoph,
>
> On 28/08/2020 22:57, Christoph M. Becker wrote:
>> Can we be certain that the relevant bits of the formerly _reserved_flags
>> are zero-filled for all existing drivers?
>
> We can, that's basically the premise of the PR itself:
>
>
23 matches
Mail list logo
