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
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/
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?
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
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.
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.
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.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
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.
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/
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_DEPRECATEDto 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_DEPRECATEDin 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.
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_DEPRECATEDto 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?
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
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_DEPRECATEDto 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?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
Hi,
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_DEPRECATEDto 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?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.
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.
On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov nikita.ppv@gmail.com
wrote:On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye pierre.php@gmail.com
wrote:On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik" lonny@lonnylot.com
wrote:On Jul 27, 2014, at 1:19 PM, Pierre Joye pierre.php@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_DEPRECATEDto 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?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.
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
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/
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
"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/
"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.
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.