On Fri, Jul 13, 2012 at 3:55 PM, Matthew Weier O'Phinney
<weierophin...@php.net> wrote:
> On 2012-07-13, David Muir <davidkm...@gmail.com> wrote:
>> On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
>> > On 2012-07-12, Sara Golemon <poll...@php.net> wrote:
>> > > --e89a8f235453d7a80104c4975c55
>> > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara <ircmax...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
