-1 Getting rid of <methodsynopsis> to solve this problem seems bad to me, can't we just improve the logic used there to have more freedom ?
without modifying the DocBook DTD or abusing the "role" attribute we can't
<methodsynopsis> was designed with C++ and Java in mind, it is just not up to the additional fexibility we have with the PHP parameter passing interface (as this example clearly shows)
and what do we get from using <methodsynopsis> anyway?
as long as we only use it for prototype rendering (and afaik this is the only thing we do?) it just makes things more complex as we have to do the following transformations
prototype -> methodsynopsis tag structure -> prototype
where the first transition has to be done by the documentation author (maybe aided by tools) *and* looses information as docbook can't express all the possibilities we have in our parameter passing API
the second transformation (within the stylesheets) then tries to recreate the original prototype (with minimal markup additions).
these two transformations do not only introduce problems
like the one we see right now with dba_fetch() as information
was lost on the first transformation so that the original
prototype can't be reconstructed in all cases,
it also makes maintainance harder as there is no simple
way to check code protos against documentation prototypes
anymore
mmm.. sure, expressed this way, I only can be OK with you :) s/-1/+1/
Mehdi
-- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
