Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Iteration tools

Posted by Ionut Gabriel Stan 
Ionut Gabriel Stan
[PHP-DEV] [RFC] Iteration tools
November 03, 2008 04:15PM
Hello everybody,

As a result of the advice given in the thread "array_key_exists BC
break", I have written an
RFC concerning some higher order functions that, I believe, could a
helpful addition to the language.

Please note that I'm a userland developer and have no clue about PHP
internals so please
forgive any stupidities I might have said in the RFC and make the
appropriate corrections.
That also means that, if positive feedback is received, this RFC needs a
developer with PHP
internals knowledge to implement it.

The RFC can be found here: http://wiki.php.net/rfc/iteration-tools

Hoping that I've made sense in what I wrote there, please feel free to
comment as you like.

Regards,
Ionut


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marcus Boerger
Re: [PHP-DEV] [RFC] Iteration tools
November 03, 2008 04:45PM
Hello Ionut,

some remarks about your proposal:

1) You can turn any array into a Traversable using
(Recursive)ArrayIterator. Though this solution is still slow. The issue is
that the c-level code needs to verify the current pointer every single time
it uses it and that means traversing the array from the beginning. That
said we might want to:
a) Optimize that for cases where we don't have to. Basically when nothing
else is pointing to the array (refcount==1) we know when the array can be
changed and do not have to verify it always.
b) provide a lower level array to traversable mechanism that operates on
the current pointer provided by the array itself. That way having no need
to verify that pointer at all.

2) Ther are iterator_apply(), iterator_to_array(), iterator_count()
The first can be used for a lot of the things you were looking for,
especially when used together with lambdas. Also not that you can use it to
pass the iterator itself to the function being called easily.

Still a few of the things you mention can be implemented faster in the same
way iterator_apply() was done. In fact the code can be based on the lovel
c-implementation provided.

marcus

Monday, November 3, 2008, 4:07:14 PM, you wrote:

> Hello everybody,

> As a result of the advice given in the thread "array_key_exists BC
> break", I have written an
> RFC concerning some higher order functions that, I believe, could a
> helpful addition to the language.

> Please note that I'm a userland developer and have no clue about PHP
> internals so please
> forgive any stupidities I might have said in the RFC and make the
> appropriate corrections.
> That also means that, if positive feedback is received, this RFC needs a
> developer with PHP
> internals knowledge to implement it.

> The RFC can be found here: http://wiki.php.net/rfc/iteration-tools

> Hoping that I've made sense in what I wrote there, please feel free to
> comment as you like.

> Regards,
> Ionut





Best regards,
Marcus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ionut Gabriel Stan
Re: [PHP-DEV] [RFC] Iteration tools
November 04, 2008 10:15AM
On 11/3/2008 17:41, Marcus Boerger wrote:
> Hello Ionut,
>
> some remarks about your proposal:
>
> 1) You can turn any array into a Traversable using
> (Recursive)ArrayIterator. Though this solution is still slow. The issue is
> that the c-level code needs to verify the current pointer every single time
> it uses it and that means traversing the array from the beginning. That
> said we might want to:
> a) Optimize that for cases where we don't have to. Basically when nothing
> else is pointing to the array (refcount==1) we know when the array can be
> changed and do not have to verify it always.
> b) provide a lower level array to traversable mechanism that operates on
> the current pointer provided by the array itself. That way having no need
> to verify that pointer at all.
>
> 2) Ther are iterator_apply(), iterator_to_array(), iterator_count()
> The first can be used for a lot of the things you were looking for,
> especially when used together with lambdas. Also not that you can use it to
> pass the iterator itself to the function being called easily.
>
> Still a few of the things you mention can be implemented faster in the same
> way iterator_apply() was done. In fact the code can be based on the lovel
> c-implementation provided.
>
> marcus
>
> Monday, November 3, 2008, 4:07:14 PM, you wrote:
>
>
>> Hello everybody,
>>
>
>
>> As a result of the advice given in the thread "array_key_exists BC
>> break", I have written an
>> RFC concerning some higher order functions that, I believe, could a
>> helpful addition to the language.
>>
>
>
>> Please note that I'm a userland developer and have no clue about PHP
>> internals so please
>> forgive any stupidities I might have said in the RFC and make the
>> appropriate corrections.
>> That also means that, if positive feedback is received, this RFC needs a
>> developer with PHP
>> internals knowledge to implement it.
>>
>
>
>> The RFC can be found here: http://wiki.php.net/rfc/iteration-tools
>>
>
>
>> Hoping that I've made sense in what I wrote there, please feel free to
>> comment as you like.
>>
>
>
>> Regards,
>> Ionut
>>
>
>
>
>
>
> Best regards,
> Marcus
>
>
>
Hi Marcus,

Thanks for your answer.

I had no idea there is an iterator_apply() function, I did a little bit
of search after you mentioned it
and found it nowhere in the docs but apparently it is present in my
5.2.6 installation. iterator_to_array()
and interator_count() are very useful functions which I had knowledge of
but forgot about them in my wiki.

I recognize that my proposal can easily be implemented in userland code
with the classes and functions
that we already have, as you mentioned already. The only real advantage
is the speed given by the C level
code and a common, standard API for array and Traversables. This way
array_map(), array_reduce() and
the like could be deprecated. I always have to look in the docs or pay a
little attention to my IDE to see
what param goes where.

Anyway, I see there's nobody else that would like this but it's ok, at
least now we have namespaces so that
I don't have to come up with ugly names like my_map() for these kind of
helper functions.


Cheers,
Ionut


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
troels knak-nielsen
Re: [PHP-DEV] [RFC] Iteration tools
November 04, 2008 10:45AM
On Tue, Nov 4, 2008 at 10:11 AM, Ionut Gabriel Stan
<[email protected]> wrote:
> Anyway, I see there's nobody else that would like this but it's ok, at least
> now we have namespaces so that
> I don't have to come up with ugly names like my_map() for these kind of
> helper functions.

I like the proposal. With the advent of first-class functions,
functional-style iteration is becoming possible. An abstraction that
hides away the difference between arrays and traversables would help
further in this direction. And this is something that is much better
implemented in the language, than in userland, to ensure
interoperability.

--
troels

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
David Z
Re: [PHP-DEV] [RFC] Iteration tools
November 04, 2008 12:50PM
Am 03.11.2008 um 16:41 schrieb Marcus Boerger:

> 2) Ther are iterator_apply()

owww that sounds like it really needs docs :>
Attachments:
open | download - smime.p7s (2.4 KB)
open | download - smime.p7s (2.4 KB)
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Iteration tools
November 04, 2008 01:25PM
2008/11/4 David Z
Jared Williams
Re: [PHP-DEV] [RFC] Iteration tools
November 04, 2008 02:40PM
"Marcus Boerger" <[email protected]> wrote in message
news:[email protected]
> Hello Ionut,
>
> some remarks about your proposal:
>
> 1) You can turn any array into a Traversable using
> (Recursive)ArrayIterator. Though this solution is still slow. The issue is
> that the c-level code needs to verify the current pointer every single
time
> it uses it and that means traversing the array from the beginning. That
> said we might want to:
> a) Optimize that for cases where we don't have to. Basically when nothing
> else is pointing to the array (refcount==1) we know when the array can be
> changed and do not have to verify it always.
> b) provide a lower level array to traversable mechanism that operates on
> the current pointer provided by the array itself. That way having no need
> to verify that pointer at all.

That would be nice.

Just written some code todo a binary search on keys, using the
ArrayIterator::seek().
It was either that or use array_keys() on potentially large array.

Jared


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login