Inheritance : super class, subclass and overriding

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
julma's picture

How do you translate your inheritance relations between classes with drupal ?

Suppose we have a super class "employee" with the three properties : name ; phone ; email and subclasses that are specific types of employees.

Then how will you implement this with drupal ?

The best way I see is to use CCK module and to share the fields of the super class between the node types of the subclasses.

The good points are that :

CCK can be seen as a class constructor in drupal. All the plugins we can find with CCK let us build our classes with more and more possibilities.

CCK will also let us override some behaviors of our super class for each sub-classes (the controller and the view methodes defined with our fields).

If we don't create a special node type for our super class, then we have an abstract class (that cannot be instanciated).

CCK let us build multiple inhéritance(http://en.wikipedia.org/wiki/Multiple_inheritance).

It would be interesting to go ahead and discuss other features involved or needed for implementing inheritance relations with drupal.

Useful links :
Definition of inheritance on wikipedia : http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29

A nice explication of dman about nodes and Inhertance
.

Comments

mfredrickson's picture

Hello,

It's nice to see someone else thinking about object oriented aspects of druapl. Sadly, I think that ship has sailed, and while many drupal concepts are "object like" they are not objects.

Let's take nodes, the classic Drupal object. Yes, one can create a subclass of node (e.g. story, a cck type, etc). However, that's where it stops. Good luck subclassing story. At best you can copy the story.module code and modify it, but you'll just be forking story, not extending it.

Next, CCK fields. Again, you can't subclass. Take for example CCK formatters. If I take and copy the text.module and another module exposes a formatter that applies to "text" types, it does not apply to my type. Even though in an inheritance system that's exactly what one would expect.

The problem is that drupal is constantly trying to make it's own poor man's object system through the use of keyed arrays. However, there is not inheritence tree for these arrays, just strings that indicating different properties. Also, there are no methods that can be dynamically dispatched, so "sub classes" (and I use the term lightly) can't override the behavior of their parent classes.

Keep thinking on this subject, but don't be fooled. Drupal is not object oriented. There are pros and cons to drupal's approach, but I often feel myself straining at the lack of a true object system.

-Mark

Two issues : Inheritence and PHP5 object syntax

julma's picture

Hi,

After reading what you said and what is said in the OOP article in the drupal API, I understand that a module himself can be seen as a subClass of the main core super classes but that we can not build a module that inherit directly from an other module, is not it ?

Here it what is said in the OOP article from the API in the "room for improvement" :

"Inheritance is also weak in the system. While, as noted above, all modules share a common set of behavior, it is difficult to extend this to new modules. One can create new modules easily that augment the behavior of existing ones, but there is not a way to override just some of a module's behavior. The impact of this can be marginalized by breaking large modules into smaller "a la carte" bundles of functionality, so that undesired aspects of a module may be more easily left out of the system."

For the discussion about keyed arrays instead of PHP5 object, I would be interested in knowing what you think of the arguments given in the original OOP article of the API.

The article refers to the drupal 4.6 and is more than one year old so is there new reasons to push PHP5 objects instead of keyed arrays now ?

There is the first argument given in the API article :

Drupal code is highly compartmentalized into modules, each of which defines its own set of functions. The inclusion of files is handled inside functions as well; PHP's performance suffers if all code is included on each page call, so Drupal attempts to load as little code as possible per request. This is a critical consideration, especially in the absence of a PHP accelerator; the act of compiling the code accounts for more than half of a Drupal page request. Functions are therefore defined inside other functions in Drupal, with respect to the runtime scope. This is perfectly legal. However, PHP does not allow the same kind of nesting with class declarations. This means that the inclusion of files defining classes must be "top-level," and not inside any function, which leads either to slower code (always including the files defining classes) or a large amount of logic in the main index.php file.

And this second one :

Why Not to Use Classes ?
The above hopefully clarifies the ways in which Drupal embodies various OOP concepts. Why, then, doesn't Drupal move in the direction of using classes to solve these problems in the future? Some of the reasons are historical, and were discussed earlier. Others, though, become clearer now that we have stepped through some of the design patterns used in Drupal.A good example is the extensibility of the theme system... In this case and others like it, the classes that on the surface simplify the system end up serving to make it more cumbersome and difficult to extend.
(see the full article to go ahead)

So let suppose it was decided to rewrite the code of drupal with the PHP5 object oriented syntax what will be look like ? What will be the benefit of it and the dark side of it now that PHP5 is more matured and now that we are in drupal 5 and soon in drupal 6 ?

"implements"

dman's picture

Hi there. I wrote that linked OO primer, in relationship to translating Drupal-think to RDF-think. Yes, that project has languished for a year :-{
I ended up biting off more than I could chew regarding recursive definitions of "what is a relationship" :-(

Now field definitions can be shared, it's easier to create inheritance-type structures by re-using elements of CCK nodes.
I've been thinking a bit more about extending CCK node types to create one or more subclasses, but then realized I didn't need that complexity, or number of different node types in any project I could see.
What we have now, with shared fields, is not inheritance, but something like an 'implements' model.
Each node type implements the ability to have a certain property, and to act on that property with get/set/display functions provided by the Drupal UI and API.

It's a bit abstract, but I can't see the use case for really taking it much further. Yet.

But the result is that we can indeed build a subclass by cherry-picking the re-usable fields (and thus the behaviours associated with those fields) and getting a result indistinguishable from multiple inheiritance.

So where is this supposed to go?

.dan.

Perfect !

julma's picture

Thanks damn.

Your explication is great !

"Each node type implements the ability to have a certain property, and to act on that property with get/set/display"

So cool !

I wish there would be a kind of community road map for CCK so that we have at a glance all the properties and the get/set/display methods that we have right now, those that are in developpement and those that we simply missing for now.

Drupal issue

colan's picture

I just thought I'd point out the Drupal issue for this over at http://drupal.org/node/100925.

Bundle Inherit is now alpha

druvision's picture

The bundle inherit module (http://drupal.org/project/bundle_inherit) , now alpha, support this functionality. Participate to make sure it goes to the core of drupal 8.x.