Shawn wrote: [snip]
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.
[snip]
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.
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.
Hear, hear! Proper use of objects provide immense benefits -- including consistency (e.g. Nick's remarks about how do I access X here, and it being different from module to module). I would rather work toward a unified, consistent object model for Drupal using classes and methods -- and arrays as data structures -- because it would eventually lead to better and more rapid development in the future. And now my 2 cents are spent. :-)