Hartmut Holzgraefe wrote:
> AFAIR (and i have to know because i did it ;) we nowadays use
> instead of within phpdoc for the
> simple reason that
> the older does not really support optional
> arguments ...
Thats ok ;)
And about stylesheets for render
when it holds the ID
instead of ? Goba?
> AFAIR (and i have to know because i did it ;) we nowadays use
>
> instead of within phpdoc for the simple reason that
> the older does not really support optional
> arguments ...
We have so many changes here that I'd have to download docbook and start
over to check that :)
I _know_ I'm going
Steph wrote:
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 hav
Gabor Hojtsy wrote:
>>> There's no reason you should change the way you document non-OO
>>> functions.
>>
>> Only to separate then from OO-functions (METHODS! METHODS!) in tag
>> level.
>
> Well, we can play with context, and there is no need to use the not
> that flexible funcsynopsys, which we ha
Or still to change all manual from
methodsynopsys/methodname/methodparam to
funcsynopsis/funcparams/parameter... And I'm not crazy ;)
What, no grep? ;)
No realy, you know ;p
There's no reason you should change the way you document non-OO
functions.
Only to separate then from OO-functions (METHODS
Steph wrote:
>> Or still to change all manual from
>> methodsynopsys/methodname/methodparam to
>> funcsynopsis/funcparams/parameter... And I'm not crazy ;)
>
> What, no grep? ;)
No realy, you know ;p
> There's no reason you should change the way you document non-OO
> functions.
Only to separat
