> Or still to change all manual from > methodsynopsys/methodname/methodparam to > funcsynopsis/funcparams/parameter... And I'm not crazy ;)
What, no grep? ;) There's no reason you should change the way you document non-OO functions. For php-gtk-doc we went the funcsynopsis route; we have functions that are global, and we also have class methods that are not uniquely named (because in GTK+ the name of the class is part of the method's name, whereas in PHP-GTK it is not). Methods are defined on the class's page as part of a <classentry> (James' home-grown solution, because we also need to include the class parent) and need the classname as part of their id as a result of this problem. I'm still bemused regarding those static functions; they fall into groups that are at present treated as meta-classes, for documentation purposes only, and again there are duplicate function names across those groups. So throughout our docs you'll see ids like <method id="gtk.gtkobject.method.get_data">, enveloping a funcsynopsis which includes the <function> tag, and referral tags such as <function class="GtkObject">get_data</function> which eventually will become links to a page named /manual/en/gtk.gtkobject.method.get_data.php, although the xml consists of a single page for the gtkobject class. Essentially James' classentry solution is very like classsynopsis/classsynopsisinfo, with additional features to fit around the problems peculiar to PHP-GTK (hierarchical structure and non-unique names). And *everybody* says it's ugly :) > http://www.docbook.org/tdg/en/html/classsynopsis.html > A ClassSynopsis contains the syntax summary of a class (generally > speaking, > a class in the object-oriented programming language sense). > > This and the <method> tag may simplifies our lives. Where did you see the <method> tag?
