On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik" <lo...@lonnylot.com> wrote: > > On Jul 27, 2014, at 1:19 PM, Pierre Joye <pierre....@gmail.com> wrote: >> >> >> However the idea to add yet other warnings/notices to ext/gd is not >> something I like to see in GD. I will rather remove many for php-next >> instead of adding more. Also some new font APIs may as well make the >> whole ttf ones less relevant, see the upstream version. > > > Pierre, > > I would only want to add E_DEPRECATED to the function calls if we are actually going to remove them.
Hm. I do not think it is a good idea. As I said, I am really not willing to add more warnings for the sake of adding them. There is no difference in the implementation whether one uses these functions or the other. A note in the doc stating that should suffice. Or do you have an argument to still do it? What would the win? > Otherwise, I agree that we should not add it. Also, I noted it in the RFC, but want to make mention here in case you did not see: I’m suggesting E_DEPRECATED in 5.6.z+1 and removal in php.next. > > On Jul 27, 2014, at 1:22 PM, Andrea Faulds <a...@ajf.me> wrote: >> >> The API signatures are compatible, yes? In which case, just make the legacy functions be aliases of the new ones. This avoids breaking everyone’s code. > > > Andrea, > > I don’t think that assessment accurately reflects the situation. I’m suggesting to change the userland API in php.next. According to the release process the whole point of a php.next is to break the API for improvements. Anyone upgrading to php.next is going to have to check for BC breaks. > > I’m suggesting having this minor change be one of the BC breaks in php.next. I’m not making the argument that it is important from a purely technical POV; I don’t believe it is. I’m making the argument that it is important from an operational POV. Removing them prevents newcomers and gurus from ever having any question about which function to use.
