On Thu, Sep 3, 2020 at 8:23 PM Levi Morrison
wrote:
> > 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
> 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 achievi
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 co
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 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.
> >
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 ar
Hi Mark Randall,
> Try as we might 4 of us working together couldn't get namespaces
> accepted. I got the feeling that there seems to be an opposition to them
> on principle, rather than the merits or drawbacks of the RFCs.
>
> Various libraries do use statics for this:
>
> Iterators::all()
M
> Perhaps we could do the same thing by introducing an items() function
> that takes an iterable and yields one array for each item in the
> iterable. The arrays contain the key/value pairs. Quoting the example
> Tyson gave:
>
> any($itemMap, fn($enabled, $itemId) => $enabled &&
> meetsAddition
On 01-09-2020 01:56, tyson andre wrote:
> Hi internals,
>
> I've created an RFC for https://wiki.php.net/rfc/any_all_on_iterable
Hi Andre,
I like the RFC, it is small and the added value is clear. The RFC
mentions the possibility of adding a first() method in the future. I
think it would be grea
On 01-09-2020 09:30, Nikita Popov wrote:
> 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 wor
On 01/09/2020 16:05, Levi Morrison via internals wrote:
Anyway, the key point I'm making is that I think a larger RFC has a
better shot of passing if we want to namespace it.
Try as we might 4 of us working together couldn't get namespaces
accepted. I got the feeling that there seems to be an
On Tue, Sep 1, 2020 at 2:08 AM Peter Bowyer wrote:
>
> On Tue, 1 Sep 2020 at 08:59, Marco Pivetta wrote:
>
> > Did the namespaces ship sail forever? Can we just have those instead,
> > please?
> >
>
> To mix metaphors: it sailed, shot down in fiery flames.
>
> Unfortunately.
>
> Peter
If we add
On Tue, 1 Sep 2020 at 08:59, Marco Pivetta wrote:
> Did the namespaces ship sail forever? Can we just have those instead,
> please?
>
To mix metaphors: it sailed, shot down in fiery flames.
Unfortunately.
Peter
On Tue, Sep 1, 2020, 09:31 Nikita Popov wrote:
>
> 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()
On Tue, Sep 1, 2020 at 9:31 AM Nikita Popov wrote:
> 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
On Tue, Sep 1, 2020 at 1:56 AM tyson andre
wrote:
> 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
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 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
19 matches
Mail list logo
