Supporting ArrayObject in array_* functions

Until now I tried to find the easiest possible solution.
Currently we have two paths to chose:

1- A class that implements ArrayAccess must be useable everywhere an
"array" is useable;
2- ArrayAccess needs to be expanded with methods for all the array
functions and ArrayObject needs to implement them;

I was choosing the approach 1 since it was easier and with less impact
on source.
Since you want something better designed, we'll have to go on 2nd option.

Please notice I do not want to override our current implementation of
arrays in PHP, but it will bring 2 main advantages:
A- It does not require hacking PHP array functions
B- It gives you an OO interface

The idea then was to keep it as an alternative, not a replacement.
What's the scope them, you may ask me. Here it is:
http://www.php.net/manual/en/book.array.php
If this implementation covers these functions, I'll be nice.

How would it be achieved?
$coll->sort(); instead of sort($coll);
$coll2 = $coll->reverse(); instead of $coll2 = array_reverse($coll);

Is this better now?

Cheers,

2009/7/30 Johannes Schlüter johannes@schlueters.de:

I'm trying to avoid a "globally solution" on first instance to avoid a
great impact on language.
If you wanna ask me what's the global solution, I'll suggest a
Collection like implementation for all array functions.

Define "all array functions" - What you're ending up with is that one
has to always look up whether a given function takes an Object of some
kind or not.

I'd rather have a "yes, unless there's something good reason not to"

This would lead to a simpler implementation. So, here are the answers
of your questions:

As said I didn't mean them as actual questions, but pointers to possible
problems in regards to a clean design.

• is that specific to ArrayObject or do we "need" interfaces like "Sortable" or "Shuffable"

All Interfaces that can be treated as normal arrays (implements
ArrayObject) should be supported.

ArrayObject is no Interface but a concrete class that means everybody
extending from there creates a is-a relationship which might be quite
limiting.

Why not ArrayAccess on first stage? I do not consider it right now
because it'll require the method getArrayCopy() to be moved from
ArrayObject to ArrayAccess.

• What should stuff like array_merge(ArrayObject, array) do

It should return an array, just like the current function prototype defines

That was a simple case, agreed, but thee might be cases where it's
probably not that clear what type should be used so again this should be
seen globally t come up with a as consistent solution as possible.

• Should we do this globally? (should ldap_set_option() allow an ArrayObject as 3rd param?)

This can be obviously be considered... but at the first step, let's be
strict to the plan an only support array operations.

Why isn't that an "array operation"? Where's the strict line? Any
function prefixed with array_? - Then sort() would be ignored. Anything
in ext/standard using arrays? Then don't forget str_replace and other
functions ... and that's not clear for users. So where's the strict
line?

Basically what would be the approach I'm looking for?
For all array_* functions, inspect if given parameter is an array or
an instance of ArrayObject.
If instance of ArrayObject, call ArrayObject::getArrayCopy() and
proceed normally with execution of each array_* function. It can't be
that hard! =)

By using getArrayCopy you are introducing quite possibly a huge
performance penalty for using ArrayObject ... creating a copy of the
HashTable just for throwing it away a moment later.

Yes, such an implementation would be trivial but I don't think it's what
we'd want.

johannes

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil

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