Class dependency aware plugin loading

I notice that you solved part of this issue by adding a loader for $module.$api.inc files. The attached patch should make it possible to let modules support multiple API versions in different files - I'm not sure if you consider that a worthwhile idea, but it doesn't really come with additional costs so the only issue would probably be best practices in file naming.

Going back to the original issue topic, this is how the current code of my class-dependency aware extension loader looks like. I thought maybe you're interested in real-world usage outside of your own killer modules :) If some of that code could be replaced by stuff in ctools, that would be neat.

Generally, the code below first retrieves the [module].transformations.inc files, then gathers the plugin files and dependencies by calling a hook (which is supposed to reside in [module].transformation.inc), and then gathers additional information about the separate plugins from each plugin file - that way, plugin info and the corresponding class can live in the same place.

/**
 * Retrieve the list of available extensions and their properties.
 *
 * @param $extensionType
 *   Either 'operations' or 'data_wrappers', depending on which extension type
 *   you want to retrieve info about.
 */
function _transformations_extension_info($extensionType) {
  static $extensions;

  if (isset($extensions)) {
    return $extensions[$extensionType];
  }
  $cache = cache_get('transformations:extensions');

  if (!empty($cache->data)) {
    $extensions = $cache->data;
    return $extensions[$extensionType];
  }
  ctools_include('plugins');

  // Call hook_ctools_plugin_api() to include the various
  // [module].transformations.inc files, taking care of API compatibility.
  $files = ctools_plugin_api_include('transformations', 'transformations',
    TRANSFORMATIONS_MINIMUM_VERSION, TRANSFORMATIONS_VERSION
  );
  $types = array(
    'operations' => 'operation',
    'data_wrappers' => 'data_wrapper',
  );

  // Call hook_transformations_[type]_info() in [module].transformations.inc,
  // in order to retrieve the file and dependency info. The ctools function
  // behaves nearly like module_invoke(), but also adds default values for
  // 'module', 'name' (= class name), 'path' and 'file' if the hook does not
  // provide those.
  foreach ($types as $plural => $singular) {
    $extensions[$plural] = array();
    $apiInfo = array('hook' => 'transformations_' . $singular . '_info');

    foreach ($files as $module => $file) {
      $result = ctools_plugin_process($apiInfo, $module, $module, $file['path']);
      if (is_array($result)) {
        $extensions[$plural] += $result;
      }
    }
    drupal_alter($apiInfo['hook'], $extensions[$plural]);
  }

  // Call [module]_operation_[className]() in the .inc file of the
  // respective plugin, for retrieving detail info without object instantiation.
  foreach (array('operations' => 'operation') as $plural => $singular) {
    foreach ($extensions[$plural] as $className => $info) {
      _transformations_include_extension($className, $extensions[$plural]);

      $function = $info['module'] . '_' . $singular . '_' . $className;
      $details = $function();
      if (is_array($details)) {
        $extensions[$plural][$className] += $details + array(
          'usesTypeOptions' => FALSE,
          'label' => $className,
        );
      }
      else {
        unset($extensions[$plural][$className]);
      }
    }
  }

  cache_set('transformations:extensions', $extensions);
  return $extensions[$extensionType];
}

/**
 * Include the file containing an operation or data wrapper.
 */
function _transformations_include_extension($className, $extensionInfo) {
  static $included = array();

  while (isset($className)) {
    if (empty($extensionInfo[$className])) {
      return;
    }
    $info = $extensionInfo[$className];

    if (!empty($info['file'])) {
      $path = $info['path'] . '/' . $info['file'];
      if (empty($included[$path])) {
        include_once($path);
        $included[$path] = TRUE;
      }
    }
    $className = isset($info['parent']) ? $info['parent'] : NULL;
  }
}

Ok. The current system works just fine for me, so whatever happens (or not) is ok with me :)

re #8: That should work great for me.

Now, one difference between my general philosophy and what you have is this:

  // Call [module]_operation_[className]() in the .inc file of the
  // respective plugin, for retrieving detail info without object instantiation.

I generally have that info as part of a registration function, so you get all the information via the _compile type hook, above, which would get a full list of all classes in the system.

I understand the intention behind that, but in my case I wanted to move the information as near to the plugin itself as possible. The data that I'm querying from [module]_operation_[className]() is really stuff that would have belonged into a static $myoperation::info() method, but that's only usable from PHP 5.3 upwards. It's just label, description, "is abstract" (can I find this out programmatically) and an operation-specific property called "type options". I want to keep this local to the plugin, in order to ensure it's properly synchronized by the plugin author when the class changes.

The full list of classes is still contained in the [module].transformations.inc file, so the _compile hook actually does compile all the classes. I could add my custom stuff via ctools_plugin_api_alter(), so that should be fine.