views:

81

answers:

2

I find myself converting between array and object all the time in PHP application that uses couchDB and Ajax. Of course I am also converting objects to JSON and back (for sometimes couchdb but mostly Ajax), but this is not so much disturbing my workflow.

At the present I have php objects that are returned by the CouchDB modules I use and on the other hand I have the old habbit to return arrays like array("error"=>"not found","data"=>$dataObj) from my functions. This leads to a mixed occurence of real php objects and nested arrays and I cast with (object) or (array) if necessary. The worst thing is that I know more or less by heart what a function returns, but not what type (array or object), so I often run into type errors.

My plan is now to always cast arrays to objects before returning from a function. Of course this implies a lot of refactoring.

Is this the right way to go? What about the conversion overhead? Other ideas or tips?

Edit: Kenaniah's answer suggests I should go the other way, this would mean I'd cast everything to arrays. And for all the Ajax / JSON stuff and also for CouchDB I would use

$myarray = json_decode($json_data,$assoc = true); //EDIT: changed to true, whcih is what I really meant

Even more work to change all the CouchDB and Ajax functions but in the end I have better code.

+1  A: 

Generally speaking, you should always use arrays unless there is a good reason to use objects. And the only good reason to use objects over arrays in PHP is if you need some sort of functionality for your data that arrays do not provide (such as private / protected variables, methods, object magic, defined structure, etc). If you're dealing strictly with data, array format is better because you can easily manipulate your data using PHP's vast array of array functions (no pun intended).

UPDATE:

If all you are doing is passing data between two points, arrays are much more suited for that purpose. The only reason (as far as I can tell) that one would ever use an object over an array as a mere container for data is if the receiving side needed a guaranteed format (think interfaces, etc).

From what I can tell, you should be returning arrays from CouchDB to avoid having to convert altogether.

Kenaniah
If I only had known this from the beginning :o I edited the question and if nobody convinces me of something else I'll go for arrays! Great answer, thank you! - karlthorwald (OP) - aka
Sorry Kenaniah, but that doesn't make sense to me. While arrays may have a lot of utility functions, that doesn't mean you should use them. If you're creating an object, then it should behave like an object and not an array. Ex., you shouldn't be able to split an object, treat it like a stack, etc.: objects are concrete things, like a user or a comment, while arrays are collections of concrete things. And if you really want to treat objects like arrays, there's always casting and ArrayObject (http://php.net/arrayobject). Hell, you can even foreach() over an object, so I don't see the benefit.
Sam Bisbee
Sam, you completely missed my point. Unless there's a *reason* that your data should be typed as an object, you should default to an array. Generally speaking, objects have greater overhead than arrays. Furthermore, they should never be used as mere data containers (unless you need to adhere to a strict contract, such as an interface). Arrays are much more suited for that purpose.
Kenaniah
Many developers who get tasked with taking over e.g. departed coworkers' PHP apps would argue that all developers ought to adhere to a strict contract.
alexantd
There is no such thing as a "mere container for data" just as there is no such thing as a box with no lid. You *always* need a way to get data in and out of the container. Methods provide a consistent, controlled, documentable way to do this.
alexantd
Alexantd, I'm afraid you also missed the argument. If I have a table in a database that contains two columns named `id` and `name`, there is no reason for me to fetch those as an object if I am simply outputting their contents through iteration. To wrap that in an object providing accessor methods would clearly be overkill.
Kenaniah
+1  A: 

It depends on the paradigm you want to work in. Fundamentally your data is all key-value pairs stored in CouchDB. Maybe it can be easily mapped to objects/entities and you are more comfortable thinking of it in terms of objects that have properties and methods. Or, maybe not and maybe you are more comfortable working with the raw data without the abstraction that classes provide. I think this is the key distinction that should inform your decision.

There is not a lot of overhead involved with objects vs. arrays in PHP. Internally they are treated similarly by the PHP engine. You might want to benchmark it yourself if it's a concern, but I think that you won't find a lot of difference unless you are pushing massive traffic or have a very constrained server. Obviously your web app would be faster if you wrote it in optimized x86 assembler, but you don't do that because you want to be able to enjoy the convenience that a high-level language like PHP provides. So execute the best design now, and optimize later, if it's even necessary.

alexantd