Re: Package proposal Science_Weather

Hi Greg, ok, sounds like an idea, not to extend PEAR, I thought that it would be required for a class and I didn't know about Cache_Lite not extending it also. The problem though is, that I need to check for errors the other packages throw, so I could write my own isError, but well... where is the point where I reinvent the wheel... as I don't use the destructor, I don't think that the overhead is that huge - or is it? Concerning the sparse documentation, I started the class 2 days ago, so I was only coding and did this function descriptions only for convenienve to already have them in the file, I'm pretty well aware, that it needs a bit of verbosity ;-) I'd like to comment on a few points you made...: On Fri, Aug 22, 2003 at 02:41:28AM -0400, Greg Beaver wrote: > [...] > > Could you provide a link to the page on weather.com that relates > specifically to this data, or at least describe in the @param tags what > they are (something like "partnerID is the username assigned by > weather.com" or "partnerID is your email address" - or whatever it is :) No, the documentation is all contained in the SDK provided by weather.com, and yes, it's a static URL, maybe I'll post it here later. Anway, on registering for the XML feed you receive an email containing two lines Partner ID: ... License Key: ... so this should be pretty obvious, but again, there's no such thing as too much documentation... > [...] > Could you describe that $unitsFormat is a 1 character string, either 's' > or 'm'? (I'm assuming here - the docs should correct me if I'm wrong) noted > It's not yet a standard, but you might want to specify which error codes > are thrown with @throws as in: > > @throws Science_Weather_Error::SCIENCE_WEATHER_ERROR_WRONG_SERVER_DATA > > This gives a little more information on which errors need to be handled > when calling a method. (If you decide against this, it won't affect my > vote) well, I'm throwing different errors in the same function... multiple @throw-lines then? Haven't looked it up in the phpdoc-code... but noted... > The @return tag for function getUnits($id = "", $unitsFormat = "") > should be @return array, not @return mixed. In addition, please > document each of the possible returns, since it's pretty clear that > there is a limited set of returns, and it's a little tricky to figure it > out just by reading the source (plus phpDocumentor-generated docs will > be more readable). I disagree, because I'm returning errors as well, so we're having arrays and objects. > [...] > If you want your package to be approved any sooner, you should provide a > link to a .phps as Arnaud requested, not everyone will have the time to > download the package and extract the source like I did. Shit, I forgot including that in my eMail, the link is http://www.pc4p.net/downloads/Weather.phps > Your code is extremely clear, and follows CS to the T. I will be very > enthusiastic when the documentation matches this level of excellence :). Like http://www.pc4p.net/pc4p/apidoc/ ;-) Regards, Alexander