Problems/Motivations
The lib/Drupal// convention is not suitable for everything, so the programmer has the option to change himself the namespace of its registered classes. This is easily done by the following snippet:
<?php
$loader = drupal_classloader();
$loader->registerNamespace('MyFancyNamespace', DRUPAL_ROOT . '/' . drupal_get_path('module', 'myfancymodule') . '/lib');
?>
This is pure glue code which is not fun to write and maintain, we could make it sexier, by allowing programmer to specify its namespace directly within the .info/yaml file.
Moreover, if you change all your modules namespace, it feels we are adding execution time because the original routine for registering namespace depends on module_list(). We can improve it.
Proposed resolution
Writing the namespace as following in the module's .info file:
name = My fancy module
description = My fancy description
namespaces[Drupal\user] = /lib
prefixes[SOME_PEAR_PREFIX] = /lib
namespaces[Symfony\Component\HttpFoundation] = /vendor
This make sense because we don't have to allocate a hook_init() for defining new classes. We can also re-factor the registering routing so that it register only the namespace needed and not the list of enabled modules, plus the custom namespaces which will overwrite default defined namespaces.
Comments
Comment #1
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedMy question is: Is there any variables/objects/functions storing/caching somewhere the .info content or this is something I have to imagine ?
Comment #2
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedFollowing #1400748: Proposal for unified namespace organization's Crell comment on info files:
I guess its a duplicate ?
Comment #3
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedAlso found in #1290658: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch]:
What happened to this ?
Comment #4
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedTrying writing a patch, I can see we are too early in the bootstrap to have the module enabled list, and that the gathering of enabled info files is expensive.
What about dumping then the autoloader or a sort of compiled version of all namespaces which is re-written on module update/disable ?
Comment #5
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedWhile thinking about another problem, which is the declaration of a special dependency for a module. For instance, when a module depends on Services 3.x or Views 3.x, instead of adding the version dependency on the .info file (@see http://drupal.org/node/542202#dependencies), they do it by a hook. Usually something like hook_version_api(). I believe they are not doing it because of their lack of knowledge that this functionality exist but more because they need more functionalities (for specifying additional metadatas).
Because loading .info files on each request is not interesting, why not introducing some kind of .INFO APIs (read-only) which will allows more flexibility for the programmer, I think this issue can be a good use case, and the hook_api_version another good one.
Comment #5.0
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedcopy.
Comment #5.1
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedUpdated issue.
Comment #5.2
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commented.info/yaml