Back as far as version 4.6 of Drupal, the decision was made not to use PHP’s class construct. This decision was made for several reasons.

First, PHP’s support for object-oriented constructs was much less mature at the time of Drupal’s design. Drupal was built on PHP 4, and most of the improvements in PHP 5 relate to its object-oriented features.

Second, Drupal code is highly compartmentalized into modules, each of which defines its own set of functions. The inclusion of files is handled inside functions as well; PHP’s performance suffers if unneeded code is included, so Drupal attempts to load as little code as possible per request. This is a critical consideration, especially in the absence of a PHP accelerator: the act of compiling the code accounts for more than half of the time to complete a Drupal page request. Functions are therefore defined inside other functions in Drupal, with respect to the runtime scope. While this is perfectly legal for bare functions, PHP does not allow the same kind of nesting with class declarations. This means that the inclusion of files defining classes must be “top-level,” and not inside any function, which leads either to slower code (always including the files defining classes) or a large amount of logic in the main index.php file.

Finally, using PHP classes to implement Drupal constructs would be difficult, due to the use of some advanced object-oriented design patterns that PHP’s OOP system doesn’t support. For instance (see following sections for details), the Drupal theme system relies on an OOP concept similar to Objective-C’s “categories”, which is not present in PHP.

Drupal Programming from an Object-Oriented Perspective | drupal.org

要は「PHP が悪い」と言ってるように読めるんだが

hatena bookmarkRaurublock on Tumblr
Comments (View)
blog comments powered by Disqus