[development] Time for a new chapter of an endless debate
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
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