About existing explanation of avoiding using classes in OOP coding for Drupal
Greetings Everyone, Is anybody care to collaborate on this (see below)? <http://drupal.org/node/547518> location contain this:
Why Not to Use Classes
The above hopefully clarifies the ways in which Drupal embodies various OOP concepts. Why, then, doesn't Drupal move in the direction of using classes to solve these problems in the future? Some of the reasons are historical, and were discussed earlier. Others, though, become clearer now that we have stepped through some of the design patterns used in Drupal.
A good example is the extensibility of the theme system. A theme defines functions for each of the interface elements it wants to display in a special way. As noted earlier, this makes themes seem like a good candidate to inherit from an abstract base class that defines the default rendering of the elements.
What happens, though, when a module is added that adds a new interface element? The theme should be able to override the rendering of this element as well, but if a base class is defined, the new module has no way of adding another method to that class. Complicated patterns could be set up to emulate this behavior, but Drupal's theme architecture quite elegantly handles the situation using its own function dispatch system. In this case and others like it, the classes that on the surface would seem to simplify the system would end up making it more cumbersome and difficult to extend.
Question is what about using already existing in PHP 5 overloading feature <http://www.php.net/manual/en/language.oop5.overloading.php>? Does authors of article on <http://drupal.org/node/547518> know about overloading feature? Could authors or anybody explain this misconception? Or point me out to already existed discussion on OOP subject. Thanks in advance
There's an issue for this in the queue: http://drupal.org/node/326881 Although, now that the page is wiki`fied, you can go ahead an edit it, if you have a better example of where Drupal's architecture works better without classes. I, for one, still think theme() is a good example, but reasonable persons may differ. -Matt On Fri, Oct 30, 2009 at 4:51 PM, <lapurd@gmail.com> wrote:
Greetings Everyone,
Is anybody care to collaborate on this (see below)? <http://drupal.org/node/547518> <http://drupal.org/node/547518> location contain this:
Why Not to Use Classes
The above hopefully clarifies the ways in which Drupal embodies various OOP concepts. Why, then, doesn't Drupal move in the direction of using classes to solve these problems in the future? Some of the reasons are historical, and were discussed earlier. Others, though, become clearer now that we have stepped through some of the design patterns used in Drupal.
A good example is the extensibility of the theme system. A theme defines functions for each of the interface elements it wants to display in a special way. As noted earlier, this makes themes seem like a good candidate to inherit from an abstract base class that defines the default rendering of the elements.
What happens, though, when a module is added that adds a new interface element? The theme should be able to override the rendering of this element as well, but if a base class is defined, the new module has no way of adding another method to that class. Complicated patterns could be set up to emulate this behavior, but Drupal's theme architecture quite elegantly handles the situation using its own function dispatch system. In this case and others like it, the classes that on the surface would seem to simplify the system would end up making it more cumbersome and difficult to extend.
Question is what about using already existing in PHP 5 overloading feature <http://www.php.net/manual/en/language.oop5.overloading.php><http://www.php.net/manual/en/language.oop5.overloading.php> ? Does authors of article on <http://drupal.org/node/547518><http://drupal.org/node/547518>know about overloading feature? Could authors or anybody explain this misconception? Or point me out to already existed discussion on OOP subject.
Thanks in advance
participants (2)
-
lapurd＠gmail.com -
Matt Chapman