[drupal-devel] multidimensional arrays VS objects. should we go for one?
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. so $menu_item->path instead of $menu_item['path']. just like we have for most 'things' like nodes, comments, terms, etc. But all these $menu_items should sit in a $items array, not in $items->item1, $items->item2. Most of this is in place already, but not all. Keeping Drupal clean means deciding on standards like these too, IMO. And oh, I am not saying that we should rewrite all this immediately, but enforcing such guidelines/standards form now on will make sure we don not introduce more inconsistancy. So, opinions?
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
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. so $menu_item->path instead of $menu_item['path']. just like we have for most 'things' like nodes, comments, terms, etc. But all these $menu_items should sit in a $items array, not in $items->item1, $items->item2. Most of this is in place already, but not all. Keeping Drupal clean means deciding on standards like these too, IMO.
Agreead. Structured data vs. list data is a good separation indicator. Goba
On Monday 10 October 2005 17:55, Gabor Hojtsy wrote:
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. so $menu_item->path instead of $menu_item['path']. just like we have for most 'things' like nodes, comments, terms, etc. But all these $menu_items should sit in a $items array, not in $items->item1, $items->item2. Most of this is in place already, but not all. Keeping Drupal clean means deciding on standards like these too, IMO.
Agreead. Structured data vs. list data is a good separation indicator.I
If more people agree, then we can make a few issues called "rewrite menu to use objects, instead of keyed arrays" and so. And add a few lines to the coding guidelines. Not that I think that menus will ever be rewritten, but it /should/ be done, if we want real clan and consisten code. Its more a thing that we can say 'from now on we do it this way' Bèr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10 Oct 2005, at 7:12 PM, Bèr Kessels wrote:
If more people agree, then we can make a few issues called "rewrite menu to use objects, instead of keyed arrays" and so. And add a few lines to the coding guidelines. Making menu elements objects will mean implementing classes and constructor functions for them, no ?
Or can you use object( 'key' => $value ) ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDSqchgegMqdGlkasRAriXAJ97KEWo9UwfVS0MKXqb+J9FIWqZ0gCfbQNz uKiWm6nZeE5oMFRdmD94nEo= =qhnG -----END PGP SIGNATURE-----
participants (5)
-
Adrian Rossouw -
Bèr Kessels -
Bèr Kessels -
Chris Johnson -
Gabor Hojtsy