On Mon, Jul 23, 2018 at 10:42 AM Niklas Keller <m...@kelunik.com> wrote:
> Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães < > m...@pmmaga.net>: > > > > On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller <m...@kelunik.com> wrote: > > > > > It'd be great to use an OO approach instead of "magic" array keys, > > > e.g. like this: > > > > > > > https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php > > > > > > Regards, Niklas > > > > > > > Hi, > > > > While I do agree with the sentiment: > > - That would have been an even greater departure from the original RFC. > > - This is currently a purely procedural API. If this were about an > > hypothetical `ResponseHeaders::setCookie` it would definitely be the way > to > > go. > > > > Regards, > > Pedro > > Hey Pedro, > > why does it have to be an all or nothing approach? It's perfectly fine > to have a function that accepts an object. > > Regards, Niklas > While defining SessionCookieParams object and use it is ok, but there is a thing to consider. How it could be more useful than current procedural API. i.e. array vs object params. class SessionCookiePrams { public $lifetime; public $path; // and so on } Users still can typo with this, so it may be class SessionCookiePrams { private $lifetime; private $path; // and so on function setLifetime() {..} function setPath() {..} } Defining such OO API is out of scope for this RFC. It would be better let users to define such OO API wrapper for the time being. If we would like to add OO API for session, it would be better to have session_oo. c or like and define OO APIs in it. It requires a new RFC for this. One thing regarding implementation. Since the internet RFC has only 2 values for "samesite", the parameter can be bool rather than string so that users can avoid "broken security by a typo". If "samesite" has more than 2 values, the INI handler can be changed so that it can handle both bool and string parameters. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
