Re: why don't most classes extend PEAR?

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? >phpversion() isn't as easy as I would hope since PHP versions are >strings with funny letters taked on afterwards and such. substr(phpversion(),0,5); should always give you the current version number without any suffixes (e.g. -dev). >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. - Martin