[development] Time for a new chapter of an endless debate

Shawn sgrover at open2space.com
Mon Jul 3 06:28:13 UTC 2006

(Disclaimer:  I only have a passing understanding of the Drupal API's, 
but do have a fair grasp of coding theory.  So take my comments with the 
proper amounts of skepticism.)

I've read through all the posts on this thread, and I think a 
fundamental point has been missed.

Objects and arrays serve different purposes.

Granted PHP does some amazing stuff with arrays, but they still boil 
down to a list of items.

Objects are different.  They represent something tangible, in a 
meaningful way, and can DO meaningful things (methods).  They HIDE how 
something is done (the encapsulation concept).  To call an object with 
something like node->render(), or node->checkAccess(uid) - well, I don't 
care how the rendering or the security check is done, but I do care 
about what those methods spit out.  This is SO much easier to understand 
in the long term, and results in much cleaner code.

In a well designed object oriented app, the flexibility of objects is 
ENORMOUS.  Properties that are themselves an object are a god send.  And 
with objects, you do not need to abandon arrays - you just change how an 
array is treated.  You treat it like the data construct it is, rather 
than trying to make it into something more meaningful by representing 
complex data.

Yes, we can make arrays in PHP do a lot of similar things as objects. 
But the resulting API is an exercise in memorizing what function does 
what, rather than looking at what methods an object has and being able 
to make some reasonable deductions.

Objects in PHP are still relatively new, seeing as (proper) support for 
them didn't arrive until PHP5.  I see Drupal now dealing with the 
resulting capabilities this buys.  As a result, Drupal seems to be in an 
"in between" spot right now - predominantly arrays, with a smattering of 
objects.  But the objects are not well planned in a big picture sense, 
and doing a wholesale change to a true OO model is quite a bit of work.

So, my thoughts on the next step is that someone needs to sit down and 
work out a class diagram that represents just what Drupal does 
currently.  Then this becomes a model to be adopted over time as 
opportunities present themselves in future updates/releases. The speed 
thing is a non issue (not enough performance gain either way).  The 
consistency thing is more of an issue, but still not the point.  The 
core question is the future design direction of Drupal.

To me, arguing to stick with an array is tantamount to saying that a 
basic data structure is all we'll ever need.  The coding industry has 
proven this mindset wrong.  But of course, arrays will always have a 
place in code.


More information about the development mailing list