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. > > 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. I cannot think of date generation use case. Is there good use case? > > 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? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
