Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 83.243.58.133 cause and error)
To: Stanislav Malyshev <stas@zend.com>
Cc: Felipe Pena <felipensp@gmail.com>, Dmitry Stogov <dmitry@zend.com>,  Lukas Kahwe Smith <mls@pooteeweet.org>, PHP Internals <internals@lists.php.net>
In-Reply-To: <4925F83E.2060609@zend.com>
References: <4900DB81.4000805@zend.com> <4900E150.1010607@dynom.nl>
	 <49018FC3.90302@gmail.com>
	 <cd5680a20810240215t4d564ab6n4a397ff22166fa83@mail.gmail.com>
	 <1224854888.19390.89.camel@goldfinger.johannes.nop>
	 <490609A1.7090400@gravitonic.com> <1225199800.878.0.camel@localhost>
	 <3F3445975B55414BB4A214B32E178657@pc>
	 <4A4FE9BC-F000-4AEE-A68C-8EFEA9DCD154@pooteeweet.org>
	 <4910D3E5.4020406@zend.com>
	 <237D5067-10C6-4D25-8CCF-FEF9FE44F6F6@googlemail.com>
	 <1225973406.5465.18.camel@felipe>  <4925F83E.2060609@zend.com>
Content-Type: text/plain
Date: Fri, 21 Nov 2008 02:36:01 +0100
Message-ID: <1227231361.3043.9.camel@goldfinger.johannes.nop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] array_key_exists BC break
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Thu, 2008-11-20 at 15:52 -0800, Stanislav Malyshev wrote:
> Hi!
> 
> > . end
> > . prev
> > . next
> > . reset
> > . current
> > . key
> 
> I think those should be more friendly with Iterators, but for other 
> objects probably not much sense to allow it. In 5.2 they modify or use 
> current hash pointer, but for objects that doesn't make too much sense.

Using iterators there might make sense, but two things to consider:
- prev() doesn't map to Iterator, so we might leave it out
- Doing that is a (silent) change in behavior, not going to the
  property's hashtable but the iterator interface, not sure if it
  hurts anybody, though .. language-wise I guess it makes more sense to
  allow iterators

> > . array_key_exists
> 
> Here it may make some sense, though I guess it should maybe go through 
> more specific handlers (i.e. has_dimension or has_property?). Also, 
> feels weird that key_exists works but in_array doesn't.
> 
> > . array_unique
> > . array_flip
> > . array_walk_recursive
> > . array_walk
> 
> Those are ok with any object, in theory, though it's not clear why you 
> could do array_flip on object but not array_reverse or 
> array_keys/values. Maybe we should not have object support from those, 
> except array_walk_* for Iterators? If you want something else, get 
> properties manually...

I don't think we should pick a single function to do iterator stuff,
especially as there's iterator_apply() doing the same thing for some
time.

> > . uksort
> > . uasort
> > . usort
> > . natcasesort
> > . natsort
> 
> These frankly make little sense with objects and also other sorts do not 
> support object, so I'd say this is just a bug that they allow objects at 
> all.

I agree.

johannes