# [RFC] imagettf* deprecation/removal - Thread: https://externals.io/message/76174 - Original archive: https://news-web.php.net/php.internals/76174 - Started by Lonny Kapelushnik on 2014-07-27T01:30:11+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76174 — Lonny Kapelushnik — 2014-07-27T01:30:11+00:00 URL: https://externals.io/message/76174#76174 Morning all, Previously I posted on the list requesting any immediate feedback on this proposal. Given the quick feedback I received I’ve made an RFC for deprecating and removing the imagettftext and imagettfbbox functions: https://wiki.php.net/rfc/imagettf_deprecation All comments welcome! ––– Hakuna Matata! Lonny Kapelushnik https://www.lonnylot.com 1.732.685.9175 --- ## #76176 — Andrea Faulds — 2014-07-27T01:38:45+00:00 URL: https://externals.io/message/76174#76176 · In reply to: #76174 > Previously I posted on the list requesting any immediate feedback on this proposal. Given the quick feedback I received I’ve made an RFC for deprecating and removing the imagettftext and imagettfbbox functions: > > https://wiki.php.net/rfc/imagettf_deprecation > > All comments welcome! Wouldn’t it be simpler to just make them aliases? -- Andrea Faulds http://ajf.me/ --- ## #76177 — Pierre Joye — 2014-07-27T04:56:50+00:00 URL: https://externals.io/message/76174#76177 · In reply to: #76176 > > > > > […] > > Wouldn’t it be simpler to just make them aliases? Indeed, and as I have no problem if Lonny likes to go ahead with this RFC, I do not think we need one for such trivial change. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #76196 — Lonny Kapelushnik — 2014-07-27T17:09:24+00:00 URL: https://externals.io/message/76174#76196 · In reply to: #76177 > > […] > > Indeed, and as I have no problem if Lonny likes to go ahead with this > RFC, I do not think we need one for such trivial change. Andrea, Whom are you suggesting the alias would be simpler for? Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. Pierre, The idea behind making this an RFC is to come to an agreement on both the change and the timeline now so there are little/no questions later. --- ## #76197 — Pierre Joye — 2014-07-27T17:19:43+00:00 URL: https://externals.io/message/76174#76197 · In reply to: #76196 > > > […] > > > Andrea, > > Whom are you suggesting the alias would be simpler for? > > Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. > > Pierre, > > The idea behind making this an RFC is to come to an agreement on both the change and the timeline now so there are little/no questions later. Yes, and I appreciate your work :) 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. I will take a deeper look at the function you refer to and see what would fit best. If a documentation only deprecation works I will go for it. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #76198 — Andrea Faulds — 2014-07-27T17:22:09+00:00 URL: https://externals.io/message/76174#76198 · In reply to: #76196 > Whom are you suggesting the alias would be simpler for? > > Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. 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 Faulds http://ajf.me/ --- ## #76201 — Lonny Kapelushnik — 2014-07-27T18:17:31+00:00 URL: https://externals.io/message/76174#76201 · In reply to: #76197 > > 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. 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. > 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. --- ## #76202 — Andrea Faulds — 2014-07-27T18:19:00+00:00 URL: https://externals.io/message/76174#76202 · In reply to: #76201 > 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. Making them FALIASes also clears up any doubts. Either is equally valid. -- Andrea Faulds http://ajf.me/ --- ## #76203 — Pierre Joye — 2014-07-27T19:30:55+00:00 URL: https://externals.io/message/76174#76203 · In reply to: #76201 > > > > […] > > > 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. > > > > […] 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. --- ## #76204 — Nikita Popov — 2014-07-27T19:47:54+00:00 URL: https://externals.io/message/76174#76204 · In reply to: #76203 > > > […] > 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? > If there are two functions doing essentially the same thing, we should remove one of them. In order to remove a function it must first be deprecated. The proposal sounds reasonable to me. There's no need to keep around legacy cruft through aliases. Nikita --- ## #76214 — Pierre Joye — 2014-07-28T07:33:27+00:00 URL: https://externals.io/message/76174#76214 · In reply to: #76204 > > > […] > > > If there are two functions doing essentially the same thing, we should > remove one of them. In order to remove a function it must first be > deprecated. The proposal sounds reasonable to me. There's no need to keep > around legacy cruft through aliases. I am not arguing about that for next but the addition of yet another warning with no gain. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #76217 — Andrey Andreev — 2014-07-28T07:49:27+00:00 URL: https://externals.io/message/76174#76217 · In reply to: #76214 Hi, > > > […] > > I am not arguing about that for next but the addition of yet another > warning with no gain. Well, you know how deprecation works ... Though, I agree with you to some extent - these functions aren't "dangerous", nor using an old algorithm that is known to be flawed, etc. Deprecation via documentation only might work better, just as long as people are aware that something will get removed in the future. Cheers, Andrey. --- ## #76223 — Nikita Popov — 2014-07-28T09:28:18+00:00 URL: https://externals.io/message/76174#76223 · In reply to: #76214 > On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov > wrote: > > […] > wrote: > > […] > wrote: > > […] > wrote: > > […] > Or > > […] > > I am not arguing about that for next but the addition of yet another > warning with no gain. > Just to clarify that I understood you correctly: Are you suggesting to remove these functions in PHP next without deprecating them first? Personally I don't have a problem with that (and if there will be no PHP 5.7 then that's the only choice), but our normal process is to deprecate functions first. Unless I'm missing any circumstances that make deprecation infeasible in this context (which I doubt, given that we even deprecated ext/mysql in PHP 5.5, which is a thousand times more heavily used than those GD function), I suggest that we stick with the usual process. Nikita --- ## #76226 — Derick Rethans — 2014-07-28T11:20:43+00:00 URL: https://externals.io/message/76174#76226 · In reply to: #76174 > Morning all, > > Previously I posted on the list requesting any immediate feedback on > this proposal. Given the quick feedback I received I’ve made an RFC > for deprecating and removing the imagettftext and imagettfbbox > functions: > > https://wiki.php.net/rfc/imagettf_deprecation > > All comments welcome! "Though this is a small change I believe it will bring significant value to the PHP community. " The only value removing functions brings is broken code. There are no functional issues with the existing functions. Leave them alone. cheers, Derick --- ## #76228 — Andrea Faulds — 2014-07-28T11:22:53+00:00 URL: https://externals.io/message/76174#76228 · In reply to: #76226 > "Though this is a small change I believe it will bring significant value > to the PHP community. " > > The only value removing functions brings is broken code. There are no > functional issues with the existing functions. Leave them alone. That sums up my thoughts on this as well. There’s nothing much wrong with the imagettf functions. If the needless duplication really bothers people, just make them FALIASes. -- Andrea Faulds http://ajf.me/ --- ## #76232 — Pierre Joye — 2014-07-28T13:11:14+00:00 URL: https://externals.io/message/76174#76232 · In reply to: #76228 > > > > > > […] > > That sums up my thoughts on this as well. There’s nothing much wrong with the imagettf functions. If the needless duplication really bothers people, just make them FALIASes. There are many areas I like to do such things, but these two functions were definitely not on my list as they do not hurt nor create extra work. I won't battle to keep them but this kind of change is the typical debatable bc break.