> > I don't think there was a formal agreement here on this...
>
> Well then should we come to a formal agreement?
>
> I dont think this sort of "magic" in the docs makes sense however the
> ":" could be used for methods that may be called statically and the "->"
> for methods that dont allow stati
Gabor Hojtsy wrote:
how are methods supposed to be listed in the manual:
foo->bar();
http://www.php.net/manual/en/function.domdocument-add-root.php
or
foo::bar();
http://pear.php.net/manual/en/package.database.db.db-common.affectedrows.p
hp
(I didn't find an example in the php manual quickly,
how are methods supposed to be listed in the manual:
foo->bar();
http://www.php.net/manual/en/function.domdocument-add-root.php
or
foo::bar();
http://pear.php.net/manual/en/package.database.db.db-common.affectedrows.php
(I didn't find an example in the php manual quickly, but I think I saw
some
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
> 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 funct
10 matches
Mail list logo
