Hi,
I like this idea very much, too but I do see the problems in doing it
correctly.
From my point of view the problem looks as follows:
PHP arrays are a wonderful universal construct but it is problematic
to use them in scenarios where you dont want to bind directly to the
single, available implementation, in order to allow a third party to
choose an implementation, as long as it fulfills the "contract" of an
array.
So rather than directly binding to the implementation it would be
useful to be able to instead just bind to a contract/interface.
That would be possible if either:
a) A class that implements ArrayAccess is useable everywhere an
"array" is useable ("array implements ArrayAccess" so to speak).
or
b) ArrayAccess is expanded and turned into a rich interface with usual
array/collection methods, many of these being direct counterparts of
array functions. Subsequently ArrayObject would need to implement
these methods, probably internally simply using the array functions on
the internal hashmap (assuming there is an internal hashmap).
I see that a) is very hard to do right and I see that b) is
problematic because of backwards compatibility and because ArrayAccess
would really no longer be the right name if it is turned into a rich
interface. A last alternative would be b) but with a new rich
interface (SplCollection?) and a new default implementation
(SplArray?) of that interface.
While a) may probably fit much better into the language because we do
not "duplicate" array functions as methods on an alternative OO API,
option b) (with the new interface+class) would probably be much easier
to implement because it keeps the current "separation" of array <->
ArrayAccess/ArrayObject/... without the need to hack any of the
existing functions.
Just my 2 cents, either way, some progress in that direction, whether
a) or b) would be very useful I think.
Thanks for reading!
Roman
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
