Hi,

On Mon, Jul 28, 2014 at 10:33 AM, Pierre Joye <pierre....@gmail.com> wrote:
> On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov <nikita....@gmail.com> wrote:
>> On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye <pierre....@gmail.com> wrote:
>>>
>>> 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?
>>
>>
>> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to