Jonathan Chaffer, long time Drupal core developer, has written up a long description about Drupal Programming from an Object-Oriented Perspective. It is a highly technical but excellent overview of many of the core concepts of Drupal programming.

Drupal often gets criticized by newcomers who believe that object-oriented programming (OOP) is always the best way to design software architecture, and since they do not see the word "class" in the Drupal code, it must be inferior to other solutions. In fact, it is true that Drupal does not use many of the OOP features of PHP, but it is a mistake to think that the use of classes is synonymous with object-oriented design. This article will cover several of the features of Drupal from an object-oriented perspective, so programmers comfortable with that paradigm can begin to feel at home in the Drupal code base, and hopefully be able to choose the right tool for the job.

The file is over on the developer's documentation site, which doesn't have commenting turned on, so feel free to use this thread to discuss it.

Comments

killes@www.drop.org’s picture

Too bad that this document finally got written. It was so nice to come up with a suggestion to rewrite Drupal in LISP or AWK after yet another request that Drupal be rewritten to use classes.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.

Jose Reyero’s picture

Very interesting read.

While I agree with the basic point of the underlying OO architecture in Drupal, and that we have functionally a kind of OO system, I'm not that sure about wheter the current one is the best way to implement it.

In fact, we are coding in PHP too many features that are already built in in PHP objects thus producing too many lines of code -that have to be parsed later- to get just an OO like behaviour.

It has advantages for the theme system, maybe, but that ones could also have been achieved just reworking a little bit the 'theme()' function. But about the node system I'd bet it could be completely rewritten using classes and maybe half of the current lines of code...
...and...
...what if we had a basic class like 'content_object' for persistent objects, which would allow to uniformly manage, at a certain level, nodes, taxonomy, blocks, users... everything... I'm just thinking here of how easy and consistent would be to implement features like access control or multi-language content...
...and...
...if you want to override only some limited behaviour of say, all node types at once... the only way now is to patch the existing module. That wouldn't be neccessary using classes...
...or...
...what about extending an existing theme that is not the base theme? Ok, copy, paste and rename.....lots of fun ;-)

So, I agree there may have been historical reasons for not going OO code from the beginning, and one of them I guess, has been poor performance and limited features of PHP objects in 4.x implementation, but that may change -is already changing-....come on... PHP5 provides interfaces, reflection, object auto-loading... don't you see any use for that?

What worries me most is that, ok, we have what we have and we must get the best out of it, but I feel like we are going in the wrong way when we opt for a 'class' free code just to keep consistency, when what we should be doing is trying these nice objects at least for the new features when possible.

And, btw, dropping classes for themes was a big step back and would have made much more sense maybe embracing classes for nodes...

So, having said that, if you think I am an unconditional zealot of OO code... you are right. I am.

As I see it, going OO is a no-brainer, just I cannot do it alone.

Cheers,

JonBob’s picture

"So, I agree there may have been historical reasons for not going OO code from the beginning, and one of them I guess, has been poor performance and limited features of PHP objects in 4.x implementation, but that may change -is already changing-....come on... PHP5 provides interfaces, reflection, object auto-loading... don't you see any use for that?"

Are you suggesting dropping PHP 4 support? Drupal only recently supports PHP 5. I think we're quite a way from requiring it.

adrian’s picture

Until php5 is installed as the base install in most hosting situations. Thus, not for several years.

--
The future is so Bryght, I have to wear shades.

Jose Reyero’s picture

Not at all. I just suggest that we look towards PHP5 and OOP and at least dont go in the opposite direction, like with the theme issue.

And... if we try some 'classes' and do some benchmarking, we better use PHP5 and maybe balance it with some PHP4 results.

One thing is to support PHP4, but a very different one is to code for PHP4.

killes@www.drop.org’s picture

I think we should get our priorities straight. /First/ we need to rewrite Drupal in LISP, then introduce classes. Not the other way around.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.

Jose Reyero’s picture

Whatever to introduce classes, LISP then :-)

peterx’s picture

PHP 4.2.0 fixed security problems in PHP 4 and then 4.2.2 fixed security problems in 4.2.0. I think 4.3.x is the minimum PHP 4 for secure code. What level is required for Drupal?

Boolean values became standard part way through PHP 4. MySQL access changed from mysql to mysqli. XML processing was rewritten a couple of times in PHP4. I use XSLT in Drupal which means PHP 5 and XSL is the easiest aproach.

Perhaps Drupal 4.8 can specify PHP 4.3.0 as the minimum level and Drupal 5.0 can require PHP 5. A roadmat for the future could include the change to mysqli.

http://petermoulding.com/technology/content_management_systems/drupal/

sepeck’s picture

This is easily found in the install.txt file you downloaded with your Drupal install. It is also found in the handbook under System Requirements.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

Steven’s picture

...if you want to override only some limited behaviour of say, all node types at once... the only way now is to patch the existing module. That wouldn't be neccessary using classes...

I don't buy this argument. Even if you have classes to take care of inheritance, you still need a mechanism for Drupal to know to use /your/ node.module or taxonomy.module replacement instead of the original.

Implementing this in our current hook system is just as much or just as little work.

--
If you have a problem, please search before posting a question.

Jose Reyero’s picture

Ok, you're right, that's a very difficult one. For that node thing I would need to think of some empty node class, which would be extended by all node types, and then implementing the functionality in some other class

But that for taxonomy is an easy one. If you think of taxonomy as an API, it can be implemented by several objects, so the core at run time just chooses the right one.

$taxonomy->get_terms()

For assigining the right object to this taxonomy object, of course you'd need some mechanism for the core to choose the right object. You dont need it now because you just *cannot* have same api implemented by more than one module, but for the special case of themes which is kind of it.

More? You now have an stateful taxonomy object you can just drop in the cache. Or menu, or whatever...

But with these difficult ones maybe I forgot to mention the more basic and easy advantage, that is, you can just implement a new node type with a dozen lines of code based on an existing one + some new functionality.

class newstory extends story {
/* Override functions here as you please */
}

Voila!, we have one more node type. No patching needed.
Same for any kind of contrib module/theme.

kbahey’s picture

A very good point that this article makes is that you can have an OO Design without mandating the use of OO Language.

This reminded me of way back when relational database were just coming out, and were in limited use commercially. We applied the normalization principles of third normal form 3NF to a system that was written in COBOL and using plain indexed files. This made design and maintenance much easier.

A bad design is still a bad design, even if it is written in the latest and greatest 100% buzzword filled technology.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

tag-1’s picture

This is a helpful piece - would've saved me lots of time figuring this all out myself a year or so ago!

While Jonathan does acknowledge the weakness of inheritance and extending modules, I hope some thought can be put into this issue.

Adding features to a node type at this point does seem to be a lot of work. Yes, they all sort of 'extend' the 'base class' of node, but that comes with a (by necessity) somewhat basic set of features. So if you need to extend an existing node type, AFAIK you basically have to rewrite (or search/replace the name and copy) the entire module, and add your code. Or modify the original code, endangering upgradeability.

I've had a hazy idea that if there were some way to 'dynamically' name a module (even if that was just the file name and/or a constant defined at the top of the module) or alias it, it might assuage this a bit, at the cost of more complexity though. The duplication involved in creating mycustomnode.module from customnode.module gives me a painful feeling (refactoring urges and DRY principles being irritated).

adrian’s picture

Or dynamically name a node type ?

CCK will make node modules obsolete... (*grin*)

--
The future is so Bryght, I have to wear shades.

Uwe Hermann’s picture

Congratulations! This made a very interesting read for me. I couldn't resist blogging about it.

Uwe.
--
hermann-uwe.de | crazy-hacks.org | unmaintained-free-software.org

Mahatma’s picture

... the issue of not being able to see little tiny classes everywhere is unsettling, but operhaps they might feel better if someone explained about the larger classes. What I mean is, PHP and the accompanying helpers like javascript seem to just flow into a larger OO class definition when applied to larger codebases.

Or to put it another way, it just won't woork unless its OOPsy. I sometimes feel like I am standing in a small forest that is also part of a much larger forest. Does that make sense?

Maybe they can't see the forest for the trees.

alex2005’s picture

I am the newcomer and one of those who want have Drupal object oriented.

Many developers need not just CMS, but framework for building sites and modules, like Delphi, Borland C++ Builder or MS Visual C++ for building Windows GUI applications.
When you develop application there, you never change standard component source code (and you may have no access to it), but all behaviour is customizable and there is no problems with upgrades.

The most powerful feature that only OOP will make possible is easy creation of custom modules inherited from standard ones.
It will be very good to have a library of standard classes that developers can use when creating their modules and sites.

For example, I needed to add some navigation links in taxonomy pages that taxonomy.module does not show. I changed taxonomy source code and now can not easily upgrade to 4.6.
Also I needed to create a block with tree view like menu have. But code in drupal works only with menus and nothing else, so I copied some functions into my module and change them a little to make them work with my objects.
You can see all changes at running site http://www.emlabs.info. It is not very different from standard Drupal but required some source code changes in taxonomy.module and taxonomy_context.module.

killes@www.drop.org’s picture

Read that article again. Drupal is already object orinted. it just does not use the darned classes.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.

teeknet’s picture

I agree. But I think I have begun to see the light in some of this discussion thanks to the gang of four's book, "Design Patterns: Elements of Reusable Object Oriented software".

Drupal is object oriented because of a design pattern that good programmers use in languages that do not support OOP thinking. In OOP languages we spend most of our time trying to figure out what should be an object, which interfaces should be inherited, etc. . . In PHP4 we spend our time figuring out how to simply make an object. I suppose one could go a level deeper and code in assembler. To do that you'll want to figure out a standard way to create functions and call them. The standard set of procedures could be called a design pattern. (I guess. . . since I really don't code in assembler. . . I've tried and quit because I didn't see the point in learning or creating a good design pattern when one already existed in C. But that was back when I was a teen obsessed with speed and games, and computers were slow.)

Reading Drupal code in OOP style kind of reminds me of reading good (and well commented :) assembler code in procedural style. Perhaps good programmers always think at least one level of abstraction above the level provided by the language. Sooner or later someone recognizes these thought patterns and writes a new language. Someone will eventually write a Drupal clone in PHP5 but no one will use it unless it's actually better. Just my two cents.

Sam Danielson

coupet’s picture

Excellent article, recommended reading.

Apache is bandwidth limited, PHP is CPU limited, and MySQL is memory limited.

Steven’s picture

Okay, suppose that we had a module system where every module is a class. You could inherit from the original taxonomy.module. Let's assume that Drupal knows that too. It is using your modified module, which derives from the original.

Now, let's go into the future. Drupal 4.7 is released, which has folksonomy/free tagging support in taxonomy.module (this is one of the first patches to go in soon actually). This change is a bunch of new functionality, so it is very likely that the member functions that you overrid in your module need changes. Or worse, there might be some bugs in your member functions, which have been already fixed in the new 4.7 taxonomy.module. You'll need to go back in and figure out how the 4.6-4.7 changes fit in with your code.

Now compare this to how you can currently do it. You keep your modified taxonomy.module in a CVS tree. When there is a new Drupal release, you check out the new version and merge your changes back in. Most changes will be merged in automatically by CVS, but the incompatible ones will be marked so you can see what parts need changing.

The promised maintainability benefits of OO design don't work on Drupal, because Drupal is a moving target. Inheritance only offers benefits if the base class is fixed. But even if we had a completely formalized OO structure, we would still need to break it constantly.

As Jonathan's article shows, the benefits of OO are in how the program is architected: how the different parts interact, what the relationship is between them. It says very little about actual code, and absolutely nothing about backwards compatibility.

--
If you have a problem, please search before posting a question.

Jose Reyero’s picture

The promised maintainability benefits of OO design don't work on Drupal, because Drupal is a moving target. Inheritance only offers benefits if the base class is fixed. But even if we had a completely formalized OO structure, we would still need to break it constantly.

About every piece of software out there is a moving target and this example about patches being better than extended classes...
I maintain some patched modules for some sites and every minor maintenance release of Drupal becomes a major nightmare when you have part of the core and a lot of modules already patched.

But, if you prefer patches, you can also patch OO code, no problem with that. And we for sure would have less lines of code and cleaner code.

So, conceding the maintanability won't be better -nor worse-. What about extendibility? -Currently you have to patch or rewrite whole modules just to get one providing a few more features.

CodeMonkeyX’s picture

First off I obviously like the current Drupal system, that's why I use it. But I think your post brings up one of the problems with Drupal.

The whole point of using OOP is to provide a fixed interface, so developers can use the framework without worrying about their code being broken with every new release. The fact that Drupal is a "moving target" is not a good thing, because as you said every time there is a new release we all have to go back in and make our modules work with it.

Eventually, I think Drupal is going to have to start making its API more concrete. Because at the moment modules and themes need to be changed with every point release.

Imagine if you have a heavily customized site with many modules and a custom theme. It can be a real pain to update your site from Drupal 4.5 to 4.6. If we had a concrete minimal public API (Does not have to be OOP) then theoretically as long as the public API stays constant all the modules that call it should still work.

Basically what I am saying is that doing CVS merges is fine when you have only one or two modules to maintain. But if you have build a large code base on top of Drupal (like we want people to do because Drupal is meant to be a "Framework") then the upgrade from each release can be daunting.

killes@www.drop.org’s picture

Our goal is to make the best Drupal that exists.
If that requires us to break the APIs we will do so. If you modify Drupal core, it is pretty much your fault. I know what I am talking about here...

Nobody is forced to upgrade.

Although stable Drupal APIs are a thing for the future, I think we are slowly converging to them. The 4.5 to 4.6 upgrade path isn't all that steep. CCK will be a larger change in the next release cycle, but after that, maybe we are closer to stability.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.

CodeMonkeyX’s picture

I was not talking about modifying the core. I was talking about people writing their own modules that use functionality from other modules, and the core.

For example, your module might make many calls to the taxonomy module. Then one day after one point release several functions in the taxonomy module suddenly return something different, take different parameters, or are simply just removed. It can be a real pain to track down what happened.

That happened to me once. A taxonomy function that I was using was just plain removed during a point release.

I agree that the goal is to make the best Drupal, but remember what Drupal is. It is a Web Development Framework! So to be the best you need to provide developers with the most stable API possible, as well as the best feature set. Personally I think if we provide a stable API then we will get more developers willing to spend time developing more feature for us.

If you want a good example, look at the theme system. A few versions ago there were very few quality themes out there. Because there was no stable API. Now there is a stable API, and a good template system. We suddenly have many more good themes available.

Hopefully by Drupal 5.0 we will have decided what we want the core todo, and have a stable, and simple API that developers can use.

JonBob’s picture

There is a lot to be said, positive and negative, about Drupal's encapsulation approach. I agree with Steven, though, that it has little or nothing to do with classes.

If Drupal were to freeze its API today, and never change anything, you'd be in just as good a situation with regard to upgrades. Whether that API is exposed as an class interface or a set of functions is irrelevant.

I personally have greatly benefitted in the past from Drupal's fluid development model, but I also would like to see some of the more mature aspects codified and be more backwards-compatible. I'm just not optimistic that we'll settle on One API to Rule Them All any time soon.

Please note that I am an OOP devoteé, would not mind at all seeing classes in Drupal, and do not defend the current approach as the best one possible. However, I am quite comfortable with using OOP techniques without the classes (hence the article), and have had personal success developing and maintaining web apps that use the framework (once I understood how to separate out my code into my own modules, rather than patch core).

CodeMonkeyX’s picture

Nicely put.

drupalninja99’s picture

People want upgrades and they want to be able to use the modules available. If you don't upgrade you can't use any new and improved modules.

I still think drupal needs to convert to classes later down the line. Inheritance really will help the system grow without so many "growing pains."

Steven’s picture

Drupal will only have a fixed interface when it is no longer being developed. That's how we've managed to keep innovating. Take a look at the changelog if you don't believe me. But you are free to stick to one Drupal version.

My point was that OO programming doesn't help at all with this. OO often makes it necessary to keep outdated and inefficient interfaces, because you supposedly don't know anything outside the black box that is your class. But I very much disagree that OO is /about/ fixed interfaces. Classes are almost always designed in terms of functionality. Drupal's functionality continuously changes. Hence OO Drupal would be at least as much a moving target as non-OO Drupal, if we want to keep the same principle of clean code.

I don't deny that upgrading core changes between major releases is hard, but I don't see how OO helps with this. In fact, it might give you the impression that your code is compatible, when your version suffers from bugs that the original module no longer has. And it is much harder to track these changes! With non-OO, there is only one module, and you are forced to merge every single change into something that works.

Take for example the 4.6 search changes. The database structure, algorithms and indexing mechanism changed. This requires that modules re-evaluate how they use the search system. Suppose we had a fixed interface which was backwards compatible, then there would be many module authors who kept using their 4.5 search code, even though it is in most cases no longer necessary. If you made a custom version of 4.5 search.module, you might as well throw it away because your changes won't fit in at all.

--
If you have a problem, please search before posting a question.

alex2005’s picture

Steven, the point is that OO structure does not solve all problems, but makes them MUCH easier.

API and internal module functionality is completely different things.
You can optimize search module and change everything inside, but it should be transparent to other modules as much as possible.
For example I'd like to have Search() function that returns search results as a list of nodes, and I do not want to know anything about database structure and algorithmes. Let the search.module developer optimize it in every version, my module should always work.

Steven’s picture

And my point was that, especially in the case of Drupal, OO offers a false illusion of security and compatibility. Inheritance /only/ works on fixed classes. Drupal's base classes WOULD change. They WOULD break. This is because of the way our development process works. If you don't like that, stick to one Drupal version, but you won't get many of the serious improvements that we continue to add in all places of the code.

Your search example is wrong, because it's not about getting search results, it's about sending content /to/ the search system so it is searchable. That requires a conscious rethinking of the module which provides the data, to make sure that it ties into the new algorithms as best as possible.

For example, we now index filtered HTML output, and use the HTML tags as hints for relative importance of words. Before, we would pass whatever the user had typed in whatever format. If your module still does that in 4.6, search will seem to work, but the results will be vastly inferior. If your input format was not HTML, but BBCode or Textile, false assumptions will be made. In fact, the new system means that many modules can now drop their search code altogether, as it now indexes visible, assembled node output rather than just a single column in the 'node' table.

Another important change was that indexing now has a throttle where it will only index up to N items per cron run. Before, it would try and index everything, which resulted in problems when re-indexing large sites. The house-keeping of which items to index was moved into the individual modules (as they are much better at this) requiring a completely different purpose and syntax of the "update_index" hook. How would an object-oriented system have helped at all here?

Back to your example however, take a look at the function which returns search results in 4.5 and HEAD/4.6:
http://drupaldocs.org/api/4.5/function/search_data
http://drupaldocs.org/api/head/function/search_data

The only parameter change was the $type, which is because now searches are done and presented per type rather than across all types globally. Note how the old syntax will in fact still work (due to usage of default values for parameters). But it's a very bad idea usability-wise to search only for nodes when you're still expecting a search for all types.

Even without OO, we seem to be doing a pretty good job of managing expectations. Other changes are documented, and you can always do a diff to see exactly what has changed.

Managing code changes is a hassle with or without OO: what matters is which versioning tools you have to make the job easier. I honestly do not believe that a formalized OO structure would help at all with Drupal.

--
If you have a problem, please search before posting a question.

moshe weitzman’s picture

wow, this really belongs in the essay itself. very well said. no amount of reasonable encapsulation could/should have shielded module developers from this change.

CodeMonkeyX’s picture

This is not a comment about OOP anymore. :)

The ever-changing Drupal interface is fine for us as developers, because we get to see new functionality incorporated quickly. But if Drupal is going to be considered viable for larger projects it is going to have to be a little more stable in the future.

Personally I do not mind reading up a little about what changed between releases, and making my module take advantage of it.

But if I were a web master for a large company and they asked me if I recommended Drupal I do not know if I would. Because I would know that if I wrote a few thousand lines of custom code based on the current release, it is quite possible that several months down the road a lot of my custom code may not work anymore.

I guess it just depends on the audience we are aiming at.

Also, saying that "no one is forcing you to update" is not good enough, people need security updates, and the new core features.

Steven’s picture

Security fixes tend to be backported to at least the previous branch. As far as "need the new features" goes, that's their problem.

But you are absolutely right that this has nothing to do with OO at all. Which was my point :P.

--
If you have a problem, please search before posting a question.

jakeg’s picture

why don't you just suggest they stick to a release rather than staying up to date with the very latest release? e.g. stick to 4.6.* rather than having to upgrade to 4.7.* straight away.

alex2005’s picture

Of cause OO structure changes, but every module can have its minimal API that can be overriden by Drupal users.

If such API changed, it will be neccessary to make changes in sources.

But most upgrades do not change APIs, just fix some bugs in modules and core. With OO structure, such upgrades can be applied for a minutes and make users always use, test and develop the latest Drupal version.

Each module can store its API version number, and automatically notify the developer if changes are required (if overridden functions use old API). This is a standard for OO COM model and it makes huge softwares such as MS Office live.

Desktop software developers have used OO approach for years, why CMS developers do not want to use their experience?

drupalninja99’s picture

Amen to that. Of course OOP can't solve problems if the base class structure changes, but it can solve a lot of problems for most minor changes.

What do people resist OOP so much?

carlmcdade’s picture

I posted this link in the mailing list a while ago. It gives good insight on where Drupal should be headed and why the present system lies somewhere between Object-oriented programming and Aspect-oriented programming. With a little effort Drupal could go fully to Aspect-orientaion and solve some of the more difficult problems with the module system.

http://www.computerworld.com/developmenttopics/development/story/0,10801...
---------------------------
Hivemindz CMSopedia
__________________________
Carl McDade
Information Technology Consult
Team Macromedia

dikini’s picture

I think there is a need to distinguish between concepts-in-your-mind, design, and implementation.

OO(object oriented) and the AO(aspect-oriented) are OK, as code but not a panacea. If they give you a better understanding when modelling or explaining something -use them. When coding - it is good to be a bit conservative.

Let me explain. I've done some OO programming in the past - It's really good n paper. UML diagrammes are great to draw and try and capture the state of the system or what a customer wants. Actually coding it - ends up as to cite Paul Graham - in a structured spagetti code. Look at a typical J2EE application for proofs.

Talking of Paul Graham - have a look at his and Jonathan Rees's, critique of Object Oriented programming explain some of the elegance of the drupal approach, although not written in LISP.

I find it easier to think of the various drupal APIs, not in OO terms but in other concepts, like callbacks, events, state machines... I'm not going to go in depth here, too much scary stuff is going on in my mind. Nevertheless regardless of how you call it, or see it - OO, AO, functional, pandemonium - the important thing is to understand and explain the under the hood mechanics, and their consequences. Then use whatever model you like to program it.

I find it easier if I have the tools allowing me flexibility to immediately code and achieve results, while allowing for higher abstraction, if required. The Drupal core APIs and the hook system practically do that.They provide you with flexible enough means to plug things into the system, to extend it.

killes: you've changed your target, I insist on haskell, or even better arc :)

carlmcdade’s picture

hh----------------------------------------------------------------------------------------------

gauravb’s picture

I am a newcomer to Drupal and this article really helped clear a lot of questions I had about Drupal architecture.

I didn't quite understand the following:

"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."

How is performance being measured? Also, why would having classes lead to lot of logic in index.php? I am very new to php Drupal so maybe I am missing something obvious :)

Steven’s picture

When you include a PHP file in another one, it's as if the code of the other file was inserted in the first. This means that when you include a file from a function, the code gets executed from within the context of that function:

function myfunction() {
  include 'foo.php';
}

If foo.php contains function definitions of its own, then you get this:

function myfunction() {
  function foo_function() {
    ...
  }
}

This not a problem, as all PHP functions are global. foo_function() will continue to exist after myfunction() is done. If 'foo.php' contains classes though:

function myfunction() {
  class foo_class {
    ...
  }
}

Then foo_class will only exist during myfunction(). After the function is done, the class will be undefined.

This means that we cannot delay inclusion of any of the PHP files with classes in them. We must load them at the beginning of every page request, even if they are not used.

--
If you have a problem, please search before posting a question.

gauravb’s picture

Thanks, that made things much clearer for me!

teeknet’s picture

I have been putting togather a simple web framework to run in php5 mostly as a skill building exercise. I have a function in a module handling class that searches for *.module files and instantiates the class contained within. The 'include' statement occurs inside a function. I have had no problems with this approach.

/* This Works */
function foo()
{
    class Bar
    {
    }
    $foFum = new Bar;
}

/* This doesn't work */
function foo()
{
    class Bar
    {	
    }
}
$foFum = new Bar;

/* Also doesn't work - no nested classes allowed */
class Nic
{
    function nac()
    {
         class Patty
        {
        }
        $Whack = new Patty;
    }
}

/* 
 * This works in php4 and php5
 */
class Nic
{
    function nac()
    {
        include 'nestincludeclass.php';
        $Whack = new Patty;
    }
}
$nic = new Nic;
$nic->nac();
$try_to_instantiate_from_global_scope = new Patty;

/* nestincludeclass.php */
<?php
class Patty
{
}
?>

Strange huh? The only difference is is that the class definition is placed in an external file and 'included' in the first. By all rights the class definition contained in the included file should be nested within the function nac(), but it is not.

If you're including a class, PHP puts it in the global namespace. I think it does this because nested classes aren't allowed.

Maybe this will help someone, though not very drupal specific.

Sam Danielson

peterx’s picture

I like classes and objects. Can we write OO and PHP 5 on the roadmap to Drupal 5.0?

The rest of my thoughts on OO and Drupal are at:
http://petermoulding.com/technology/content_management_systems/drupal/ob...
along with descriptions of my OO modules for Drupal at:
http://petermoulding.com/technology/content_management_systems/drupal/mo...

robertDouglass’s picture

I think someone's already working on the Smalltalk version.

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

dikini’s picture

I'm working on a lisp one, if anyone is interested. I'll drop CLOS though. Have a distaste for that.

kbahey’s picture

This is absolute heresy ...

Rober and Vlado, you should help Dries with his project of moving Drupal to Java!

(And here is the smiley :-) )
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

peterx’s picture

My Grandpa talks about entering binary code direct into computers using rows of switches. He says that created jobs for millions of programmers. Grandpa likes Java.

petermoulding.com/web_architect

Gary Feldman’s picture

The link to the article in the base note is wrong (as of this writing). The correct link is now http://api.drupal.org/api/HEAD/file/developer/topics/oop.html

Gary Feldman

kbahey’s picture

Thanks for pointing it out. Updated now.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

peterx’s picture

the inclusion of files defining classes must be "top-level," and not inside any function

I use the PHP 5 auto include of classes and class files are not included until you use the object. We should look at module abc having class xyz in file abc/xyz.class, and have the auto include pick up the correct file. That would solve a major objection to a classy Drupal.

The article discussing object orientation needs updating to the current PHP 5.

petermoulding.com/web_architect