Very nice! Does this mean, however, that the traditional hook-based workflow will get replace by an event-driven one? Or will this change be more of a end-user transparent change in core and for modules defining hooks?
At the very least (if we are on PHP 5.3) we could have something like:
namespace drupal\dblog;
at the top of every file.
Files in the includes directory would have:
namespace drupal;
The only time 'drupal' would be seen in a function name would be when calling an API function in a different module, e.g.
\drupal\system\flush_caches();
1) We've been discussing how and if to leverage PHP namespaces in Drupal 8, now that we have access to them in PHP 5.3. To date most of the discussion has been on tricking out modules-as-namespace, a discussion that has stalled as it is a much more complicated problem space than it seems at first glance.
There are three ways to access a file in a file system:
Relative file name like foo.txt. This resolves to currentdirectory/foo.txt where currentdirectory is the directory currently occupied. So if the current directory is /home/foo, the name resolves to /home/foo/foo.txt.
Relative path name like subdirectory/foo.txt. This resolves to currentdirectory/subdirectory/foo.txt.
Absolute path name like /main/foo.txt. This resolves to /main/foo.txt.
After a good chunk of discussions, all were in agreement to scale back the scope of the initiative to just the "Web Services" piece, and spin off the Layout/blocks/related-UI parts to a separate effort.
Furthermore, some efforts, such as PSR-0 and Unified Plugin system, were only semi-related to the WSCCI initiative in the first place, and just happened to become relevant for it. Work on those efforts will continue as part of the general Framework community efforts.
