Doc #64872 [NEW]: setcookie explanation shows optional args in brackets with open ending or depth

From: Date: Fri, 17 May 2013 18:28:08 +0000
Subject: Doc #64872 [NEW]: setcookie explanation shows optional args in brackets with open ending or depth
Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-9843@lists.php.net to get a copy of this message
From:             sascha dot lorahn at web dot de
Operating system: Win XP
PHP version:      Irrelevant
Package:          Documentation problem
Bug Type:         Documentation Problem
Bug description:setcookie explanation shows optional args in brackets with open ending or depth

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 bug report at https://bugs.php.net/bug.php?id=64872&edit=1
-- 
Try a snapshot (PHP 5.4):   https://bugs.php.net/fix.php?id=64872&r=trysnapshot54
Try a snapshot (PHP 5.3):   https://bugs.php.net/fix.php?id=64872&r=trysnapshot53
Try a snapshot (trunk):     https://bugs.php.net/fix.php?id=64872&r=trysnapshottrunk
Fixed in SVN:               https://bugs.php.net/fix.php?id=64872&r=fixed
Fixed in release:           https://bugs.php.net/fix.php?id=64872&r=alreadyfixed
Need backtrace:             https://bugs.php.net/fix.php?id=64872&r=needtrace
Need Reproduce Script:      https://bugs.php.net/fix.php?id=64872&r=needscript
Try newer version:          https://bugs.php.net/fix.php?id=64872&r=oldversion
Not developer issue:        https://bugs.php.net/fix.php?id=64872&r=support
Expected behavior:          https://bugs.php.net/fix.php?id=64872&r=notwrong
Not enough info:            https://bugs.php.net/fix.php?id=64872&r=notenoughinfo
Submitted twice:            https://bugs.php.net/fix.php?id=64872&r=submittedtwice
register_globals:           https://bugs.php.net/fix.php?id=64872&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64872&r=php4
Daylight Savings:           https://bugs.php.net/fix.php?id=64872&r=dst
IIS Stability:              https://bugs.php.net/fix.php?id=64872&r=isapi
Install GNU Sed:            https://bugs.php.net/fix.php?id=64872&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64872&r=float
No Zend Extensions:         https://bugs.php.net/fix.php?id=64872&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=64872&r=mysqlcfg



Thread (2 messages)

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