Subscribe to our bi-weekly audio podcast - The Lullabot Drupal Podcast, our daily interview snippets - Drupal Voices, our periodic videocasts,
or everything. Just choose your favorite podcast-listening application
or service and click away!
Drupal Voices 21: Larry Garfield Explains Object-Oriented Programming
Title: Drupal Voices 21: Larry Garfield Explains Object-Oriented Programming
Album: Drupal Voices
Year: 2009
Length: 10:22 minutes (5.76 MB)
Format: Stereo 44kHz 77Kbps (VBR)
Larry Garfield of Palantir.net talks about the differences between Procedural Coding and Object-Oriented Programming as well as the vertical extensibility of OOP.
Larry was very involved with the Go PHP 5 initiative to encourage hosting providers to upgrade from PHP4, and as a result of the success of this effort, Drupal 7 will be the first release that will require PHP5. For the first time, Drupal will be able to use the more evolved Classes and Objects features of PHP5.
On April 28th, 2009 Anonymous (not verified) said:
Awesome interview. There are a few things that I don't really understand, though.
He mentions that Drupal is horizontally extensible using modules and hooks, but that it's hard to do vertical extensible. What exactly does that mean? He seems to say that procedural code is used for horizontal extendability and object oriented code used for vertical extendability. Is that true?
Disclaimer: I am somewhat making those terms up myself; they're not an industry standard term as far as I know. :-)
By horizontal extensibility, I mean things like form_alter. Modules can extend Drupal "sideways".
By vertical extensibility, I mean replacing existing systems or behavior rather than augmenting them.
For example, there are hooks for modules to add new stuff to the search system. There is no built-in support for changing the search engine itself, however, without disabling the search module and starting entirely from scratch.
Have a look at the first diagram in the remote data blog I posted recently. That should make it clearer what I mean. You can add more stuff horizontally next to what's already there, but changing what's already there in the stack is harder than it should be. That is, however, something that OO is inherently very good at. You just have an object that conforms to an interface, and then you can swap it out for another object of the same interface and keep working (assuming the way you instantiate the object is properly designed).
See the blog posts mentioned in the Handlers issue (the first "here" link in the summary) for extensive background on the subject.
I Googled briefly for a resource on the distinction between vertical and horizontal extensibility and didn't find one, so thanks for creating the definitive source. :)
Comments
Horizontal vs Vertical Extensibility
Awesome interview. There are a few things that I don't really understand, though.
He mentions that Drupal is horizontally extensible using modules and hooks, but that it's hard to do vertical extensible. What exactly does that mean? He seems to say that procedural code is used for horizontal extendability and object oriented code used for vertical extendability. Is that true?
Vertical vs. Horizontal
Disclaimer: I am somewhat making those terms up myself; they're not an industry standard term as far as I know. :-)
By horizontal extensibility, I mean things like form_alter. Modules can extend Drupal "sideways".
By vertical extensibility, I mean replacing existing systems or behavior rather than augmenting them.
For example, there are hooks for modules to add new stuff to the search system. There is no built-in support for changing the search engine itself, however, without disabling the search module and starting entirely from scratch.
Have a look at the first diagram in the remote data blog I posted recently. That should make it clearer what I mean. You can add more stuff horizontally next to what's already there, but changing what's already there in the stack is harder than it should be. That is, however, something that OO is inherently very good at. You just have an object that conforms to an interface, and then you can swap it out for another object of the same interface and keep working (assuming the way you instantiate the object is properly designed).
See the blog posts mentioned in the Handlers issue (the first "here" link in the summary) for extensive background on the subject.
Thanks Larry
I Googled briefly for a resource on the distinction between vertical and horizontal extensibility and didn't find one, so thanks for creating the definitive source. :)