Doc->Req #60566 [Bgs->Opn]: Highlight prototype changes

From: Date: Thu, 29 Dec 2011 19:54:05 +0000
Subject: Doc->Req #60566 [Bgs->Opn]: Highlight prototype changes
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-7714@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=60566&edit=1 ID: 60566 Updated by: philip@php.net Reported by: martinb at online dot ie -Summary: Highlight that 3rd argument $matches only became optional in 5.4.0 +Summary: Highlight prototype changes -Status: Bogus +Status: Open -Type: Documentation Problem +Type: Feature/Change Request Package: Documentation problem Operating System: Ubuntu 10.04 PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Yeah, the "bogus" label is questionable but it's been here since the 90's. One day someone will change it, I reckon, and perhaps that day we'll also change "Wont fix" to "Won't fix" although I like that one. :) I wonder if we could add a little trickery to make the prototype changes clearer, in terms of versioning? Maybe a little [note] overlay of some sort, and/or a simple indication. Probably only for the phpweb version. So this bug report is turning into a feature request for something along those lines. But to be clear: This is not asking for version specific PHP manuals. Previous Comments: ------------------------------------------------------------------------ [2011-12-29 19:42:17] martinb at online dot ie Hello? Please relabel the report "Closed" or "Rejected" or something accurate. Failing that please remove it and my email address from your system. ------------------------------------------------------------------------ [2011-12-22 11:09:17] martinb at online dot ie The backwards compatibility of the *documentation* is affected because it's misleading. This isn't like other cases where a parameter is made optional and defaults to some value, this is a fix to a usage case of preg_match_all (counting instances) where the matches parameter should never have been required and thus it's natural to assume it's always been the case. Re "Bogus": words matter. If you don't mean bogus then please relabel the report "Closed" or "Rejected" or something accurate. Failing that please remove it and my email address from your system. ------------------------------------------------------------------------ [2011-12-21 21:38:43] frozenfire@php.net Please don't take the marking of your bug as "bogus" to be an insult. What often occurs is that we go through a slew of bugs quickly and weed out the ones we won't or cannot fix. Bogus usually means that a submitted bug asks for a solution which would be contrary to our documentation style. In this case, we usually only represent changes to functions in the changelog. It's rare that we will make additional mentions of changes, and those are only in cases where backwards compatibility is severely effected. ------------------------------------------------------------------------ [2011-12-21 19:16:51] martinb at online dot ie Did I say they shouldn't? Other changes to functions are highlighted at the top of the document: fgetcsv is a particularly good example. Also, is it standard to mark rejected bug reports as "Bogus"? Whether this gotcha (got me anyhow) merits highlighting may be moot but the report is not bogus, and it's pretty objectionable to be so labelled. ------------------------------------------------------------------------ [2011-12-21 14:29:46] bjori@php.net No, all changes to functions are described as changelog entries See http://www.php.net/manual/en/about.phpversions.php for more details on which versions we document. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60566 -- Edit this bug report at https://bugs.php.net/bug.php?id=60566&edit=1

« previous php.doc.bugs (#7714) next »