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.
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 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 commentedFollowing #1400748: Proposal for unified namespace organization's Crell comment on info files:
I guess its a duplicate ?
Comment #3
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 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 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 commentedcopy.
Comment #5.1
sylvain lecoy commentedUpdated issue.
Comment #5.2
sylvain lecoy commented.info/yaml
Comment #19
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #20
smustgrave commentedSince there has been no follow up in 3 months going to close out. But don't worry this can always be re-opened!
Thanks