Doc #64872 [Opn->Nab]: setcookie explanation shows optional args in brackets with open ending or depth

Edit report at https://bugs.php.net/bug.php?id=64872&edit=1 ID: 64872 Updated by: cmb@php.net Reported by: sascha dot lorahn at web dot de Summary: setcookie explanation shows optional args in brackets with open ending or depth -Status: Open +Status: Not a bug Type: Documentation Problem Package: Documentation problem Operating System: Win XP PHP Version: Irrelevant -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: Hm, I don't see that there's anything wrong with the function prototype of setcookie (except that has too many optional arguments, but that is not a documentation issue). Anyway, the structure of the function prototypes in the PHP manual is explained on <http://php.net/manual/en/about.prototypes.php>. Previous Comments: ------------------------------------------------------------------------ [2013-05-17 18:28:07] sascha dot lorahn at web dot de Description: ------------ --- From manual page: http://www.php.net/function.setcookie#refsect1-function.setcookie-description --- the explanation is still wrong, allthough it is true, that there is a possibility of an open field or range like a vector in the parameter, which in that case would appear as an (inner) array in the (outer) space limiting parameter. so you have to speak of the possibility of putting a simple variable as an argument in argument position one next to eg. an variable of type stack, which in that other case then, would be able to realize that or nearly any type of enlargement of the limiting. the normal case should be a quantity of not more than two argument possibilities within the parameter, in special cases there has also to be a solution for an implicit returning argument, also known as the result, which in other cases of course, would appear on argument position two. this btw for function declarations and definitions of at least a signature which brings for most later cases then the Ability with it, to be handled very easy and also comfortable in aspects of better re-reading and -understanding by the programmer. the opposite lies in functions which have to read out those arguments and their values. they offer for this reason an absolute parameter with a lot of (implicit) resulting argument "interfaces" for a later retrieving of the vals in such special value-compilations, as described above. that is why it lies also in the interest of a better programming documentation, to differ these cases in best manner. to go along with already builded and known conventions for spoken or written languages like you find them in every dictionary, is therefore the only true solution. this means, that also the parameter description(s) for php needs a more simple structure for its logically correctness(es). A dictionary speaks of an option for words within a listing or not, which are brackets like [...] as the option of a possibility for leaving them out. so that means in that simple case, that there is no room-construct for those bracketed values possible, which otherwise could remember the programmer of but possible euler-solutions, he might have still forgotten. i am sure php.net means the same by providing nice answer pages like the one, i have experienced a moment ago and that this now mentioned "mistake", has once been created for a better understanding of its learners. but it is still a mistake... Actual result: -------------- but it is still a mistake... you wrote, that the documented open range in the parameter which the reader can find in the function-documentation is closed by the first argument of the function, which you call "S..." and which seems to be supposed as an interpretation possibility for a span or an spanning value. if you incorrectly enlarge your parameter with an open range, you are in risk to create overspans. this means eg. for energy saving green state systems, that they possibly have to overpower that "function". if you have a type "stack" in usage, instead of using that not really defined span with a decision await-state cycle in mind, you are more earlier absolute precise in those then not longer possibly power-saving questions. another little mistake, i do not like anymore. greetz. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=64872&edit=1