Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61200
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <36.A6.17670.8E820005@pb1.pair.com>
References: <CAF+90c-eG_+7ZpGzu-ownYnTDUvVJwHgCH=xOvnOa9sAYKNHjA@mail.gmail.com>
 <1342050547.1456.33.camel@guybrush> <CAAyV7nGg=LwgLADXRP5b+LE79qJTRjf63J-3CgFyWmb6aJAieA@mail.gmail.com>
 <CAESVnVpF1fQv0E2fzsOP1vUX5+myVn00a47ceZeNpKuuCS+XSA@mail.gmail.com>
 <D8.3A.46517.587EEFF4@pb1.pair.com> <4FFF6C9C.2080802@gmail.com> <36.A6.17670.8E820005@pb1.pair.com>
Date: Fri, 13 Jul 2012 16:16:17 +0200
Message-ID: <CAMUwpuQgtJqRxv_6rT4JDCXnBn+_ORAFRGQG9sa2D=Yjv-jnSw@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Internal iteration API
From: jpauli@php.net (jpauli)

On Fri, Jul 13, 2012 at 3:55 PM, Matthew Weier O'Phinney
<weierophinney@php.net> wrote:
> On 2012-07-13, David Muir <davidkmuir@gmail.com> wrote:
>> On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
>> > On 2012-07-12, Sara Golemon <pollita@php.net> wrote:
>> > > --e89a8f235453d7a80104c4975c55
>> > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>> > > > One thing to keep in mind when doing this is to think about consistency.
>> > > > I think that's a huge point not to be taken lightly. For that reason, I
>> > > > think that this API should not be used for any of the array_* functions.
>> > > > Meaning that array_sum(), etc should all take arrays only.
>> > > >
>> > > > Then, other non-array functions (such as str_replace, etc) can be modified
>> > > > to use this new method.
>> > > >
>> > > > Just my $0.02 anyway...
>> > > >
>> > > Sounds like everyone agrees the API is useful, just question marks over
>> > > which existing methods should profit by it.
>> > >
>> > > To add my $0.02, it'd be nice to work in a zend_parse_parameters() type for
>> > > this.  Keep extension code clean and ensures any temporary iterators get
>> > > destructed.
>> > Another note: if this comes to fruition, since arrays and traversable objects
>> > would in many cases be interchangeable, it would be nice to have a type-hint for
>> > "array-like" behavior:
>> >
>> >     function doSomething (ArrayLike $options) { ... }
>> >
>> > A better name could likely be used, but you get the idea.
>>
>> What about extending the array typehint include ArrayAccess, and extend
>> the Traversable typehint to include arrays?
>
> This would work for Traversable, as that interface does not define any methods,
> and the only use case would be for iteration. This would answer most use
> cases/issues I've had (need either an array or Traversable in order to iterate).
>
> For arrays, however, it's a bit harder, as the reason for typehinting on array
> may not be solely access of members, but _also_ iteration. As such, extending
> the array typehint to include ArrayAccess could lead to issues when the object
> implementing ArrayAccess does not also implement Traversable. I don't think this
> would work at all semantically.

Yep, today we have :
- arrays
- Object implementing ArrayAccess
- Objects implementing Traversable (Iterator)
- array_****() functions not working with ArrayAccess' objects
- Iterator API not working with arrays (ArrayIterator needed)
- ... I forget things

There sure is something to do with that to make a consistent API.
So what would be the right answer to make all those ideas join in a
sane way everybody agree with ?
I got no clue, but I think we should answer this Q for 5.5

Cheers,

Julien.P