> On 21 Oct 2016, at 13:32, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > Hi Stephen, > > On Fri, Oct 21, 2016 at 1:38 PM, Stephen Reay <php-li...@koalephant.com> > wrote: >> 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) > > I'm lazy enough not to add new function entry point because the patch > is to show how it will look like. > > Making aliases make life a little easier for both user and developer. > I don't think we will deprecate (I mean deprecate and remove in the > future) old functions. It will be there to avoid needless > incompatibility. >
I’m not quite sure I understand. I thought the whole point of new standardised function names is to allow eventual deprecation and removal of the inconsistent/confusing names? >> >> 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? > > I have an idea to enable HttpOnly by default. Most applications will > be safer by this change without any problems, but some applications > may need to disable HttpOnly. So it's better to stick with key => > value pairs in case we change the default. > That’s a good point. So perhaps anything with a boolean value becomes a keyword only? (i.e. keep it generic, with as little special-case handling of keywords/named values as possible) > I cannot think of date generation use case. Is there good use case? What do you mean? You can’t think of a situation where the developer would be setting a cookie expiry date, or you can’t think of a reason to cast a date time object to a string? Right now, it *only* accepts a unix timestamp, and then converts to a string (effectively doing date(DATE_COOKIE, $expires)). If you’re designing an api to support modern use, I would suggest that supporting DateTimeInterface objects or strings makes much more sense that requiring a unix timestamp. Like I said, I could live without the object support, and just let it cast any value to string, but *requiring* a timestamp only to convert back to a string seems odd to me. If you want to be universal, treat int’s as timestamps, cast objects to a string and send strings (casted or not) as-is. > >> >> 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). > > Good idea. It's not updated since 90's, I guess. The same topic pops > up on occasion. > > https://tools.ietf.org/html/rfc6265#section-5.1.1 > Do we have this algorithm somewhere already? I don’t know the internals, but DATE_RFC1123/DateTime::RFC1123 is available in userland and seems correct to me. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
