Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61198 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64041 invoked from network); 13 Jul 2012 13:55:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jul 2012 13:55:52 -0000 X-Host-Fingerprint: 208.107.183.205 host-205-183-107-208.midco.net Date: Fri, 13 Jul 2012 09:55:52 -0400 Received: from [208.107.183.205] ([208.107.183.205:20008] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 36/A6-17670-8E820005 for ; Fri, 13 Jul 2012 09:55:52 -0400 Message-ID: <36.A6.17670.8E820005@pb1.pair.com> To: internals@lists.php.net References: <1342050547.1456.33.camel@guybrush> <4FFF6C9C.2080802@gmail.com> User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 208.107.183.205 Subject: Re: [PHP-DEV] Internal iteration API From: weierophinney@php.net (Matthew Weier O'Phinney) On 2012-07-13, David Muir wrote: > On 13/07/12 01:04, Matthew Weier O'Phinney wrote: > > On 2012-07-12, Sara Golemon wrote: > > > --e89a8f235453d7a80104c4975c55 > > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara 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. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc