Re: How to document a type of int / float?

Hi, I would prefer that authors update their source to include the <?php ?>, as this is better documentation practice. I am of the opinion from a few years of experience now that the less magic there is in interpretation of docs, the better. I think that either QA or the doc group could hassle authors to do this in the same manner they were hassled to handle get_class() problems :) I have good news for parse errors - phpDocumentor 2.0 will be using PHP_Parser, which generates the exact same parse errors that PHP's parser generates, because it uses a generated parser based on zend_language_parser.y. So, within a year's time, expect that this will catch all the parse errors prior to commit. Greg Quoting Mehdi Achour <didou@keliglia.com>: > greg@chiaraquartet.net wrote: > > Hi, > > > > I use | as the separator, not / int|float. phpDocumentor parses | to > > mean "either or" as in "either int or float", and also will check to > > see if > any > > of the words are classes. > > > > I'll get these issues and the & fixed in 1.3.0 final, which will be out > > sometime in the next month, I think > > great ! > One more thing, is the examples generated by phpDocumentor ? if so, can > you add <?php and ?> around the PHP examples ? > This will help cleaning the manual from parse errors in the example > (turning short_open_tag to Off and calling php -l on each xml file) > > thank you in advance ! > > didou > > > > > Greg > > > > Quoting Stefan Neufeind <stefan@neufeind.net>: > > > > > >>Hi, > >> > >>in reference to the recent discussion raised by didou about a > >>&type.int/float; in the image-graph-docs I wonder how this should be > >>documented in phpdoc. We could surely define all these occurences as > >>type mixed, however I don't think this is a benefit to the > >>documentation. But mentioning only int or float also makes no sense, > >>since the function can accept both without problems - despite other > >>functions that maybe demand an int. > >> > >>A similar question appeared to me at places where either an int or a > >>string may be supplied. What's the best way to document this? Using > >>mixed everywhere and just giving "mixed here means int or string" in > >>the comment doesn't sound like a good solution for me. > >> > >> > >>Regards, > >> Stefan > >> > >