Description:
------------
As you probably know, objects extending or implementing certain classes and interfaces from the SPL allow for special array syntax.

e.g. the array-push idiom on the ArrayAccess interface:
  <? $ArrayAccessImpl[] = $element; ?>

...or the foreach-loop on Iterator:
  <? foreach($ArrayIteratorImpl as $element) { ... } ?>

...ArrayObject even allows for the list-each idiom:
  <? while(list($k,$v) = each($ArrayObject)) { ... } ?>


This is a nice feature, which I very much appreciate. However, it is error prone as it is not complete. The avarage PHP user, none-OOP programmer and not-about-type-caring guy will certainly fail to replace arrays with ArrayObject and that alike, as it simply is not the same. It's just the same syntax for two different semantics.

I like the idea to be able to implement my own Collection classes and iterate over instances just like in Java. Taking that road however requires me to implement my own utility methods like 'sort()' and derivates (yes, some build-ins fail to sort an $ArrayObject) and replacements for all those high-performance array_* methods.
Replacing those is necessary because the only common thing ArrayObject and array do share is in fact the special array syntax I mentioned before - plus some functions that 'magically' work.
Refactoring existing functional code to OOP design patterns is a pain, if not impossible, but desired to reduce development costs.


I hereby request some improvement on ArrayObject and its siblings, ie. 
- a better integration with the already existing array_* functions, so that ArrayObject and derivates can be considered real arrays.
- a richer set of predefined interfaces and utility classes like ArrayAccess and Iterator that allow any implementing class to be used in certain array context, eg. Sortable, Comparable, Mergable, Walkable , etc.
- maybe a collection interface just like in Java, with 'Array' being the most versatile class -- implementing most of the interfaces.


...or maybe just some more 'magic functions' that allow the prior, but cripple PHP's emerging OOP approach.

Reproduce code:
---------------
$ArrayObject = new ArrayObject();
$ArrayObject[] = 'foo';
$ArrayObject[] = 'bar';
$ArrayObject[] = 479;

sort($ArrayObject);
var_dump($ArrayObject);

$values = array_values($ArrayObject);
var_dump($values);

foreach($ArrayObject as $key => $value) {
  var_dump($key, $value);
}

var_dump(is_array($ArrayObject));

Expected result:
----------------
string(6) "sorted"
object(ArrayObject)#1 (3) {
  [0]=>
  string(3) "bar"
  [1]=>
  string(3) "foo"
  [2]=>
  int(479)
}
string(6) "values"
array(3) {
  [0]=>
  string(3) "bar"
  [1]=>
  string(3) "foo"
  [2]=>
  int(479)
}
string(8) "is_array"
bool(true)


Actual result:
--------------
<b>Warning</b>:  sort() expects parameter 1 to be array, object given in <b>...</b><br />
string(6) "sorted"
object(ArrayObject)#1 (3) {
  [0]=>
  string(3) "foo"
  [1]=>
  string(3) "bar"
  [2]=>
  int(479)
}
<br />
<b>Warning</b>:  array_values() [<a href='function.array-values'>function.array-values</a>]: The argument should be an array in <b>...</b><br />

string(6) "values"
NULL
string(8) "is_array"
bool(false)