Re: Looking towards PEAR2?

Travis Swicegood wrote:

Howdy all, Joe Stump wrote:

Per our amazingly shortsighted CS I thought of a serious problem having to do with the "Major new revisions must be named PackageX where X is the new major version". What happens when PEAR moves to the next major version? Will it ship on PHP as PEAR2? Will I then have /usr/bin/pear and /usr/bin/pear2? Will there be two different directories containing PEAR modules (one for ones installed via PEAR 1.x and one for ones installed via PEAR 2.x)? Will PHP ship with both and then, at compile time, you'll have to choose which one to install? Per the CS rules the package will HAVE to be named PEAR2. Does this mean I'll have to change all of my PEAR::isError()'s to PEAR2::isError()?

This would actually be a case for instantiating pear objects instead of relying on static methods. To me, statics seem serve the same purpose as namespaces for functions. Out of curiousity, know the reasoning behind using statics so pervasively? -Travis Well its pretty much this, if your using pear error, the result from pretty much every method needs to be checked with an isError call. No one wants to extend pear just to get an isError function.

So this leaves you with either reimplementing isError on your own class, or calling is error statically. There are other cases like this as well, but in the end making an object to check for isError and most other utility type functions just doesn't make sense. An object should encapsulate data and provide methods that work on that data. Utility methods get the object there working on passed in, hence static makes sense. -josh