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

[Chris Johnson]

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.  :-)