Re: why don't most classes extend PEAR?

Chuck Hagenbuch wrote: > > Quoting greg keraunen <gk@proliberty.com>: > > > It would be nice if there were some way in which the cvs hierarchy > > reflected which classes extend PEAR.php and which do not. > > I don't think that's a good way to go. For instance, how would you have the > hierarchy reflect the fact that a package had it's own, added-functionality > error class, which naturally extends PEAR_Error? I.e.: Point well taken. And thanks Martin for the tip on PHPDoc @extends; that is all I wanted to see. I guess I am initially struck by the 'namespace collision' in that PEAR is used to embody the idea of a php code repository AND also is the name of a particular class. It might have been better if the PEAR class had a different name than that of the code repository. But as long as the coding standards allow easy sorting and inspection of relationships between classes and packages I guess that is almost enough... except for the problems of inter-dependencies of versions of various classes. Has this issue been sorted out yet? In my application, for example, I want to do an initial sanity check at runtime to make sure that I have at least the minimal version of PHP. It would be nice to check versions of dependent PEAR classes too. phpversion() isn't as easy as I would hope since PHP versions are strings with funny letters taked on afterwards and such. Has there been any discussion of a standard versionID format for all PEAR classes? (consistent with PHP?) Or is this going to be handled by some build/release process for PEAR? But if PEAR is a repository and not a class library then that wouldn't make sense. Could rpm be used to handle package dependencies in PEAR? - greg