Re: why don't most classes extend PEAR?

On Thu, 06 Sep 2001 02:13:36 -0700, greg keraunen wrote: >Martin Jansen wrote: >> The classes, which don't extend PEAR simply don't need the feature set >> served by the PEAR base classes. So it would be simply a waste of >> execution time to include/require the PEAR class. > >I guess PEAR is primarily a code repository like CPAN. Right: PEAR is related to CPAN in some points (unfortunately I don't know anything about the details of CPAN). But we have the goal to better than CPAN one time :-). >But the overhead of PEAR.php doesn't seem too high since it only really >contains error handling and destructors. Well, the overhead may be not that high, but at least it is there. >Most classes that don't extend PEAR require(PEAR.php) it and use the >error handling stuff so I don't see how that would save much in >execution time to extend PEAR. Am I missing something? In that point you are right: At every place, where error handling is used, people should use the PEAR error handling of course. If they haven't done that yet, they will probably do that in future releases once they find the time or once they discover the power of the PEAR class. >It would be nice if there were some way in which the cvs hierarchy >reflected which classes extend PEAR.php and which do not. In PHPDoc (which is the documentation standard for PEAR) programmers can use the keyword @extends, that describes from which other class the current class is derived. I don't think it is necessary to show that in the directory structure. Why do you want this? - Martin