[drupal-devel] multidimensional arrays VS objects. should we go for one?

Chris Johnson chris at tinpixel.com
Mon Oct 10 15:24:35 UTC 2005


Bèr Kessels wrote:
> Hi,
> 
> When designing the patch for hook_links to return structured data, instead of 
> that accursed string, I found that we have no "good practice" nor consistency 
> in core when to use objects and when to use keyed arrays.
> 
> So, Is it an idea to discuss this at druopalCON, to discuss this here? Or does 
> it not really matter to others? 
> 
> I would prefer to have One Method. 
> using structured arrays would mean converting all(!) $node->foo (and the 
> likes) stuff to $node['foo']. While using the other one would probably mean 
> changing all (haha) form api stuff to objects, but certainly all menu items.
> 
> I think it is doable like it is now, but that it is just Not Very Clean. (and 
> will result in problems, like we had for php5)
> 
> IMO the clean way is to have arrays when the data is NOT structured, but is a 
> list of similar items, but to have objects when it is structured. 

I disagree that there should be one method only for passing data.

I agree with Bèr that we should use arrays when the data is a list of similar 
items and objects when it is "structured."  I would go further and say we 
should use objects when the thing being manipulated is a first-class object, 
or when the data being passed is clearly attributes of something that should 
be an object.

I realize that my foregoing definition doesn't help much because so many 
people will interpret it differently.  Thus, for core, I believe we should 
define what things are objects.  Anything not on the list is not an object. 
That list should be fairly short.  For example:  node, user, vocab, feed?, 
comment?, form?, template?, menu?.  (? == unsure)

Contrib module authors will have to try to make intelligent decisions about 
whether any structured data they introduce is an object, or not.


Chris Johnson
--
Skype: chrisxjohnson
IRC:  chrisxj




More information about the drupal-devel mailing list