Hi Yasuo, > On 20 Oct 2016, at 19:21, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > Hi Ptephen, > > On Thu, Oct 20, 2016 at 9:15 PM, Stephen Reay <php-li...@koalephant.com> > wrote: >> As with Niklas, I have no vote, so my *only* option to prevent what I >> consider to be a bad decision, is to post to this thread and hope that >> enough of those who *do* have voting rights, reject the proposal. > > It's okay, but aren't I and framework developers on the same side?
Apparently not. I expect people using my work to read the documentation. I don’t remove mysql support because they don’t understand why a “DELETE * FROM foo” query deleted all their data. Similarly I don’t see why it’s a bug to remove headers when you leave $replace to the default of true. > > I don't want to get bug report that session lost or some important > cookie lost somehow. Why is your concern so focussed on solving problems for inexperienced developers, who are effectively using functions incorrectly, at the expense of experienced developers who are doing the right thing? This response effectively encourages bad behaviour (did the reporter even check the docs for header() to see why it’s replacing the session cookie? How many bug reports do you think you’re going to get saying “header() no longer supports set-cookie headers”. > > Framework developers don't want to get bug report that user logouts or > some important cookie lost somehow. > > It's better that we have header*() and cookie*() function for > dedicated purpose, isn't it? Having dedicated functions for setting cookies, yes that makes sense. Removing that functionality from header() makes no sense. A cookie is still a header. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
