Re: Re: Package proposal Science_Weather

Hi Arnaud, This is a personal choice. I have started using @param string blah because of the risk of typos. PhpDocumentor 1.x does not return a warning if a @params parameter name does not match an actual parameter. Why? /** * @param string the format string * @param string $args... an unlimited number of strings */ function sprintf($format) { } Variable arguments can't be documented if we are strict. Version 2.0 will fix this (once error handling is fully fixed in PEAR, so that we can raise notices) by raising a notice if a parameter name does not match. I've found that when parameters change names, it is more convenient to avoid the $varname in the parameter, because it will shunt to a new parameter definition, but that is a personal choice. If you are meticulous, the way listed below works just fine. Greg LIMBOURG Arnaud wrote:

     /**
     * Sets the neccessary account-information for weather.com
     *
     * @param    string      $partnerID
     * @param    string      $licenseKey
     * @access   public
     */
     function setAccountData($partnerID, $licenseKey)

Which brings me to a question greg. I notice you write the parameter variable like $partnerID in the phpdoc. However, when it's not there but the @param tags are in the same order as they appear in the function() definition, phpdocumentor parses this intelligently. So what is the ways to go ? @param string $var blah or just @param string blah I switched to the last one since it works very well. Arnaud.