Hi again, On Sun, Jul 22, 2018 at 6:47 PM, Pedro Magalhães <m...@pmmaga.net> wrote: > On Sun, Jul 22, 2018 at 1:16 PM Andrey Andreev <n...@devilix.net> wrote: >> >> 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(). > > > I thought your comment was about session_set_cookie_params only because > your reasoning about lifetime (as a relative amount of time) being a PHP > construct only makes sense there.
I've been unclear about this, indeed. But I don't see why you thought I was talking about it as a relative value in particular, nor how my arguments would only make sense for session_set_cookie_params() ... If anything, that's the one place where my arguments aren't as strong, because cookie-related settings are only a small part of the session handler. The primary motivation for all my thoughts so far has been to follow the IETF standards as close as possible, and (as opposed to all other parameters) cookie attributes are *computed* from the lifetime/expire/expires input, regardless of whether it is an absolute or relative value. Thus, I would like for that distinction to be obvious in the function design. That's not all of my reasoning, but more on that below ... > So I'm not sure why for set[raw]cookie the expires attribute would be > treated different from the others? Max-Age is derived from it, but the value > you pass to expires will be directly used in the cookie attribute (although > in a different datetime format). Some other attributes are also not used > verbatim. For instance, 'secure' being true or false also means they > `secure;` attribute being present or omitted. > Thinking again from the perspective of the user, I would find it annoying to > have the expires attribute separate from the others. > Well, you only note the different format as a side thing, but it is still a kind of derivation. As a side note touching on the absolute vs. relative thing from earlier, I'd argue that if set[raw]cookie() was designed today, it would accept a relative value (Max-Age wasn't a thing until PHP 5.5 IIRC, so it wasn't a factor in the original function design). Anyway ... If semantic purity is unimportant, I could also ask why by the same token you don't want $name and $value to be part of the array params? How are these 2 parameters less of an inconvenience than $expires (or whatever you call it)? We have to draw the line somewhere and it has to be clear; turning $expires into an array key/value pair seems arbitrary to me. Last, but certainly not least, we talk about $expires here only becase that's how it's (currently) named in either documentation and/or reflection. But for all intents and purposes it may as well be named $fooBar and it wouldn't matter as long as it is a concrete parameter, whereas an associative array key name is very important. Now I'd have to remember if it actually is "lifetime", "expire" or "expires" ... or is it "max-age"? Not only that, but if it is either "expires" or "max-age", I would rightfully have reasons to believe that the expected input should be match the actual Set-Cookie attribute instead of a PHP-specific value. That's very unintuitive and I believe we have a general consensus on this list that array parameters are somewhat evil. You have to remember that the only reason we're doing this here is to avoid parameter creep with potential for infinity, and nothing else. And yes, Secure and HTTPonly don't go as is in the Set-Cookie header, but those are natural edge cases that I'm sure everybody undestands. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
