1

I'm writing pluggable system. For a given name, I want to test if there is defined class pluginActionName. If it is, I want to create an instance of it. If it's not, I want to create an instance of pluginAction (parent class for all pluginAction* classes). That's the easy part, and Drupal unrelated.

Difficult about Drupal is to know when classes are defined. Can I rely on class_exists

  • in my .inc code outside actual class? no?
  • in initializers for static properties? no?
  • in static methods of my class? sometimes?
  • in dynamic methods of my class? yes?
  • in helper functions that will be called by methods? only if it would be OK in method?

In italics is what I figured out so far, but I'm not sure about this and I cannot figure out exact loading order to tell why it's the way it is reliably.

2
  • The answer depends on your Drupal version. Can you update with which version you are using? Commented May 24, 2013 at 10:09
  • 1
    I left Drupal version out of it, because if there are differences between 6 and 7, I want to know them too. And a link to Drupal 8 methodology wouldn't hurt. I'm using 7 right now but I want this as general and universal as possible.
    – Mołot
    Commented May 24, 2013 at 10:46

1 Answer 1

3

Drupal 7 introduces a code registry - an inventory of all classes and interfaces for all enabled modules and Drupal's core files. The registry stores the path to the file a given class or interface is defined in, and loads the the file when necessary. The registry loads classes and interfaces on demand, via php's built in class autoloading mechanism. Modules can now move all code for classes that are not regularly used into an include file, and Drupal will only load it on demand. This will cut down on the amount of code loaded per request, and reduce Drupal's memory footprint.

more info:

8
  • So, in Drupal 7 I can safely load other module's classes at any point, and code registry will take care to make them available, right? No chance for a class reference used to soon?
    – Mołot
    Commented May 24, 2013 at 10:53
  • If the class is added to the module.info file, e.g files[] = myClass.class.php it will be autoloaded, e.g $object = new myClass($params); Commented May 24, 2013 at 10:55
  • As long as the module author uses the new mechanism, you'll be OK. Commented May 24, 2013 at 10:57
  • 1
    @Mołot the .info mechanism as highlighted by David above is reliable. This does not rely on a naming convention. Commented May 24, 2013 at 11:05
  • 1
    I'm not sure it works at /any/ stage. at hook_boot for example you generally have a very restricted set of APIs and other modules are not loaded so even if class loading works (not sure, as I say), other functions required by classes won't be available. Commented May 24, 2013 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.