Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76217 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33323 invoked from network); 28 Jul 2014 07:49:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Jul 2014 07:49:19 -0000 Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.51 as permitted sender) X-PHP-List-Original-Sender: narf@devilix.net X-Host-Fingerprint: 209.85.218.51 mail-oi0-f51.google.com Received: from [209.85.218.51] ([209.85.218.51:56352] helo=mail-oi0-f51.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 11/82-26001-E7006D35 for ; Mon, 28 Jul 2014 03:49:18 -0400 Received: by mail-oi0-f51.google.com with SMTP id g201so5656740oib.38 for ; Mon, 28 Jul 2014 00:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devilix.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qxFwiZGn37dI4yeq3E5G6+96nIoq+EwowzimvsEfhig=; b=lTQj2AYChc0vKccKUXsHBeTD9IXiRSzgRXTdrZKCYqQyO9pZ3nvvXJw750xnfeugKN zraB72ai1EKwhCi3KhKfQ5EYEFsIgsjYzf4CmPfMmZTGHMmcW6ppQGZqQ4Di0/UNS45j KG7ZKj+Y7atasF3t+4yfmYXL8ijWIAVskJeGI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qxFwiZGn37dI4yeq3E5G6+96nIoq+EwowzimvsEfhig=; b=ByJSrgH2JY0teQ24jSCMVPGyidY5fscJ07TQYODtdsO5IVwgPcJtUZXNDMyiWdQ4xH i9rERnADvG0JOgRMPRGr5iszDS/j44BduQ9ffh10g76bGGE5TVTkRyZqdv8BL17Ocisl DDfj2B0o2VUM0InV4VQaH+pypdPgwoQUV7OrxsZqy8FUFsqSfHKE/Vs6W2gUKMUCq1oX qjpLctkcL/l51KPTieYO+r5gDuz0e2YkOTogQBaGMPBiNWhbWssbTi9R+3qnc0M2j2I4 A7Lg507/LL6SwJeAU3ep13mMnCZVfEgjxgEca1pp4kQ3kojyPFTqq0vHfb3tDERVY3pX c1Hg== X-Gm-Message-State: ALoCoQlJo8sv6fdTOFJqhofdgwswRbrylnGKOElLUyJpthfZh1IlJ/nLDJzFrOZyOi90IREmDdl/ MIME-Version: 1.0 X-Received: by 10.60.123.103 with SMTP id lz7mr47889454oeb.18.1406533767173; Mon, 28 Jul 2014 00:49:27 -0700 (PDT) Received: by 10.202.75.205 with HTTP; Mon, 28 Jul 2014 00:49:27 -0700 (PDT) In-Reply-To: References: <482DEC36-8A5A-4840-910A-3C63CA3A503B@lonnylot.com> <77BCF83D-F7AF-4853-8C40-D07D1CFFF8DE@lonnylot.com> Date: Mon, 28 Jul 2014 10:49:27 +0300 Message-ID: To: Pierre Joye Cc: Nikita Popov , Lonny Kapelushnik , PHP internals , Andrea Faulds Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] imagettf* deprecation/removal From: narf@devilix.net (Andrey Andreev) Hi, On Mon, Jul 28, 2014 at 10:33 AM, Pierre Joye wrote: > On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov wrote: >> On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye wrote: >>> >>> On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik" wrote: >>> > >>> > On Jul 27, 2014, at 1:19 PM, Pierre Joye 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.