Feedback from Drupal

Well, apparently no one invited Drupal to this party, so forgive me for jumping in anyway. :-) I only just found out about it from Planet PHP. I am one of the lead developers for the Drupal project (Database subsystem maintainer, specifically), and one of the ones pushing hard for Drupal to adopt more object oriented techniques (we often joke that it is "the last great procedural project", although I don't know if that's actually true) and more industry-standard approaches and standards. So I am very much in favor of more inter-project communication and standardization. That was actually one of the key goals behind the GoPHP5 project (http://gophp5.org/), of which I was the lead organizer and in which several of the projects listed here participated. That said, I do not in any way speak for the Drupal project or community. I am speaking for myself as an interested party who would like to be able to support this effort. As others have noted, I have severe misgivings about the way this effort is being handled. Rather than repeat them all, I will simply echo the statements made by Greg Beaver, Brian Moon, and Rasmus Lerdorf, as they already covered the main procedural issues I have. As to the proposed standard itself (and I refer to it as such because for anyone who wasn't in the impromptu meeting that is all it is at the moment), I would offer the following hopefully constructive feedback, from the perspective of Drupal: **Namespaces** Namespaces should be all lowercase and must follow the following conention: <vendor>\<package_name>\ Examples: <?php namespace pear2\text_diff; namespace zend\controller; Underneath each namespace, the package can declare further sub-namespaces and classes. Each level under the namespace must be in a new directory and classes must map to the traditional PEAR1 style class name to directory structure. A patch will be submitted to php-src for PHP 5.3.x that will modify the SPL autoload functionality to attempt to autoload classes in the include_path using this schema. ***************** The namespace convention itself is not a problem, I think. However, is the package level necessary? In our case, mapping packages to modules would make a great deal of sense (drupal\views, drupal\node, drupal\user, etc.), but there's plenty of "global" code that wouldn't make sense to force into a package. It would be better to just leave at the drupal\ level. Adding an extra layer would only make the code harder to understand. Also, the directory structure is incompatible with the way Drupal works. Drupal modules can live in a number of different places, and their code is deliberately path-agnostic. (This gives us an enormous amount of flexibility.) Tying namespaces to directory paths would be impossible without a gut rewrite of the entire system. Instead, for Drupal the forthcoming Drupal 7 we developed an introspective registry where the system parses its own code and builds up an index of where every function and class lives, and then our autoload implementation queries that as necessary. (I was one of the people who developed that system.) So if the standard mandates a Java-style class/directory structure (although Java's classloader is swappable with others beyond the common one), then it is impossible for Drupal (or any other project that isn't structured that exact way all the way down to the file names) to ever adopt even if we wanted to. If as follow-up comments suggest it is simply that approach would get automatic support from SPL but you can still use a different mechanism, then we're OK as that approach wouldn't inherently break Drupal. **Class and Interface naming** All classes, interfaces, and abstracts must begin with an uppercase character. They may contain additional capital letters and underscores. Any underscores in class names will be converted to the DIRECTORY_SEPARATOR when attempting to auto-load. Interfaces must be suffixed with Interface, abstract interfaces must be suffixed with Abstract. The only exception is a package base exception, which may be an interface or concrete class, but shall always be 'catchable' with: catch (vendor\packagename\Exception $exception), more details on exceptions in the Exceptions and Exception Handling section below. *************************** Upper-case: Wait, you mean there are standards that don't do that already? :-) Underscore conversion: See comments above regarding the inflexibility of that approach. Interface suffix: We've already adopted that for the Interfaces we're introducing in Drupal 7. Abstract suffix: We have no standard here yet, but there's so few abstract classes so far that we should be able to adopt it without issue. **Exceptions and Exception Handling** Each package must provide a base exception of the following name: vendor\package\Exception This exception may be either an interface or class (concrete or abstract). Each exception thrown by "vendor\package" must throw exceptions that either extend or implement this base exception. *********************************** I've read the follow-ups here, and frankly, um, I still don't get it. Why must that exist? What's the benefit? Granted I am not working in a heavily OO and exception-using world, but I still don't understand what the advantage is here. And no mention of naming conventions for exceptions, such as FooBarBazException? I'd have expected to see that in there. :-) -- Larry Garfield larry@garfieldtech.com