Re: why don't most classes extend PEAR?

Martin Jansen wrote: > > On Thu, 06 Sep 2001 11:30:05 -0700, greg keraunen wrote: > > >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? > > The PEAR installer, that is currently in development stage, will be > able to inform the user about the dependencies the class, he is > installing, has. In future versions it will perhaps also be able > to do a dependency runtime check. > > I'm not fully involved in this installer thingie. Perhaps someone > with more knowledge on this can clue us in a bit. Tomas? Now the best approach to the dependencies issues it's from the Stig's rfc. Read the doc at: http://cvs.php.net/co.php/pearweb/rfc/003-dependencies.txt?r=1.1 and feel free to discuss/implement what you want ;-). > >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? > > The maintainer of a PEAR class will decide at what time he releases > a new version. So it is IMO his job to keep track of the versioning. Stig from time to time, writes interesting docs :-). Here is the one related to software versioning: http://cvs.php.net/co.php/pearweb/sql/design.txt?r=1.6 And was another for CVS Tags.. umm.. let me find.. ah here: http://php.net/manual/en/pear.standards.cvs.php Tomas V.V.Cox