Is it normal to alter (or support multiple) function signatures like this, when
you want to improve the name *and* improve the signature? Wouldn’t you just
leave setcookie() as-is, introduce the new cookie_* functions, and then
deprecate set cookie later? (ala mysql => mysqli)
As for the specifics - I kind of like.. Niklas (I think?) suggestion where the
flags array accepts either key => value pairs, or non-keyed flag values. Any
non-string key is ignored and the value used as a ‘flag’ (e.g. HttpOnly,
Secure). Any non-string value would be casted to string.
This would obviously require slightly different usage by developers - the user
would need to send a date/time (either a string or object that will cast to a
string in the right format) instead of a timestamp for expires. If you want to
special-case it, you could type-check for an instance of \DateTimeInterface and
run ->format(\DateTime::COOKIE) instead of just casting to string, but I don’t
think I’d consider that to be essential really. If the user can generate a UNIX
timestamp, they should be able to format it to RFC1123 themselves too, no?
While you’re looking at this. DateTime::COOKIE (and DATE_COOKIE) seem to be
using RFC850 format, but with a 4-digit year. Besides being a bit of a
mis-match of formats, RFC850 is considered “obsolete” now, and perhaps should
be replaced by RFC1123 (basically, no dashes, short day name).
Cheers
Stephen
> On 21 Oct 2016, at 09:51, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> On Fri, Oct 21, 2016 at 9:35 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>> On Thu, Oct 20, 2016 at 9:21 PM, Niklas Keller <m...@kelunik.com> wrote:
>>> Before we even discuss disallowing `header("set-cookie")`, we should have a
>>> sane cookie API, e.g. one that like `setcookie($name, $value, $flags)`.
>>>
>>> That's also the way we implemented it in Aerys
>>> (https://github.com/amphp/aerys/blob/9a7327f062aa678408dfe4f4c3c7f479db16f187/lib/Response.php#L49-L58).
>>> It's a simple wrapper around `addHeader` to make life easier, but it doesn't
>>> restrict developers to call `setHeader` and replace all `set-cookie`
>>> headers.
>>
>> We choose current API for reason. It does not look pretty.
>> This is patch allow array config for 3rd param for setcookie().
>>
>> https://gist.github.com/yohgaki/b86e07cd450777422c1a467166cd2fd3
>>
>> I suppose some of us will have opinions having this kind of code(s).
>>
>> Any comments?
>
> Execution example.
>
> [yohgaki@dev github-php-src]$ cat t13.php
> <?php
> setcookie('A', 'B', ['httponly'=>1, 'path'=>'foo',
> 'expires'=>time()+999, 'secure'=>1, 'domain'=>'example.com']);
> setcookie('A', 'B', ['httponly'=>1] );
> setcookie('A', 'B', 999);
> setcookie('A', 'B', time()+999);
>
> echo 'OK';
> [yohgaki@dev github-php-src]$ ./php-cgi t13.php
> X-Powered-By: PHP/7.2.0-dev
> Set-Cookie: A=B; expires=Fri, 21-Oct-2016 02:55:31 GMT; Max-Age=999;
> path=foo; domain=example.com; secure; HttpOnly
> Set-Cookie: A=B; HttpOnly
> Set-Cookie: A=B; expires=Thu, 01-Jan-1970 00:16:39 GMT; Max-Age=-1477016533
> Set-Cookie: A=B; expires=Fri, 21-Oct-2016 02:55:31 GMT; Max-Age=999
> Content-type: text/html; charset=UTF-8
>
> OK
>
> If PHP has named parameter, we don't need this patch.
> Dose anyone working on named parameter?
>
> One issue of this patch is strict types. It ruins strictly typed
> parameter because array option parameters won't be checked by PHP.
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
