Am So., 22. Juli 2018 um 14:16 Uhr schrieb Andrey Andreev <n...@devilix.net>: > > Hi, > > On Sun, Jul 22, 2018 at 2:21 AM, Pedro Magalhães <m...@pmmaga.net> wrote: > > On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev <n...@devilix.net> wrote: > >> > >> Yes. > >> > >> All other "options" are actual *cookie attribute* names, as defined by > >> the various IETF RFCs, while "lifetime" is just a convenient name used > >> by PHP. It doesn't correspond to a particular attribute, but instead > >> the values for the Expires and Max-Age attributes are derived from it. > >> I believe during discussion I insisted that the parameter be called > >> "attributes", for this very reason. > > > > > > Hi, > > > > While I do understand your reasoning, I find it extremely unfriendly to the > > user of the function to ask for one parameter separate from all the others > > for that reason alone. > > Also, keep in mind that all this function does is set the `session.cookie_*` > > ini entries. So all parameters are treated equally. > > > > Ok, I can see how it can be inconvenient for > session_set_cookie_params(), though calling it "extremely" unfriendly > is some exaggeration IMO. But while I didn't quote that part of your > message, you did also suggest to apply the same decision to other > functions and so I am talking about all of them. > > I'd be ok with this for session_set_cookie_params() alone, but not for > set[raw]cookie(). > > >> > >> On another note, I also wanted that pretty much any key/value pair to > >> be accepted instead of raising an error, for forward compatibility. > > > > > > I really believe that the user spotting errors like `['expries' => time() + > > 3600]` faster is more valuable than FC. > > > > Honestly, the fact that you chose "expires" for this particular > example IMO only makes a stronger case for why it needs to be > separated. :)
It'd be great to use an OO approach instead of "magic" array keys, e.g. like this: https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
