Re: array_key_exists BC break

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