There's an issue for this in the queue:<br><br><a href="http://drupal.org/node/326881">http://drupal.org/node/326881</a><br><br>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.<br>
<br>-Matt<br><br><br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 4:51 PM, <span dir="ltr"><<a href="mailto:lapurd@gmail.com">lapurd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<tt>Greetings Everyone,<br>
<br>
Is anybody care to collaborate on this (see below)? <br>
<a href="http://drupal.org/node/547518" target="_blank"><http://drupal.org/node/547518></a> location contain this:<br>
<blockquote type="cite">
<h2>Why Not to Use Classes</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</blockquote>
Question is what about using already existing in PHP 5 overloading
feature
<a href="http://www.php.net/manual/en/language.oop5.overloading.php" target="_blank"><http://www.php.net/manual/en/language.oop5.overloading.php></a>?<br>
Does authors of article on </tt><tt><a href="http://drupal.org/node/547518" target="_blank"><http://drupal.org/node/547518></a>
know about overloading feature?<br>
Could authors or anybody explain this misconception?<br>
O</tt><tt>r point me out to already existed discussion on OOP subject.<br>
<br>
Thanks in advance<br>
<br>
</tt>
</div>
</blockquote></div><br>