On Sun, Jul 22, 2018 at 6:54 PM Andrey Andreev <n...@devilix.net> wrote:
> 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. > Hi Andrey, Well, "expires" is what ends up in the cookie header itself so I think that it's simple to remember. But I do understand your arguments on semantic purity and the fact that Max-Age is derived from it but I still believe that in this case, it's not worth the distinction. If there ever comes a new attribute that won't be used verbatim, what would we do? Leave it between $expires and the options array and break all existing code? Leave it to the end of the signature to avoid the BC break but then we are left with something really awkward? Given that we understand each other but we just disagree on what is more important, I'd really like to hear someone else's opinion. If we are to get something into 7.3 (which I believe we should due to https://github.com/php/php-src/pull/2613#issuecomment-401266510) and with the feature freeze in one week, we should reach an agreement on what to do very soon. Regards, Pedro
