[development] Time for a new chapter of an endless debate
chris at tinpixel.com
Mon Jul 3 19:09:02 UTC 2006
> 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.
> 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.
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. :-)
More information about the development