Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76223 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47010 invoked from network); 28 Jul 2014 09:28:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Jul 2014 09:28:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.48 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.218.48 mail-oi0-f48.google.com Received: from [209.85.218.48] ([209.85.218.48:64786] helo=mail-oi0-f48.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8B/D4-26001-8A716D35 for ; Mon, 28 Jul 2014 05:28:09 -0400 Received: by mail-oi0-f48.google.com with SMTP id h136so5730314oig.21 for ; Mon, 28 Jul 2014 02:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6+WrquH5AssZm7hiUxfIB3g5CSIFR4LwfUyAijsXYLk=; b=ue5ox9jKXfD5VEEoXVuQcoDfDt35fV2DOLRUwj9ARgcL0aA9kuxbWGUfpM2sSBGzgD wjogv5MLC9ndNgjkDyWMDIIdWwE9wjVRtVW5XVGmYdaQAD6GVgQR5qJOI9/aWum13aK9 PZQuhtPglyPmhBz6e5IUdt1i1I2w1gN6KFN3cKb98MDriyVyb3nccP67brVZ97XDEKdt IqGVF0CsRs1Q+MxtLWM+OleVRG0jzc8ALg7BnIPVqebmfQCAWEwA01iBwebeTiaxFutD uSsV6cIuKjbDJxkXiYo8gttxE5kjK4qbwAAIMBkAIn5/7AjAWnFH/NU5rsMe9lNRGrvY UE6A== MIME-Version: 1.0 X-Received: by 10.60.160.38 with SMTP id xh6mr11794102oeb.82.1406539698093; Mon, 28 Jul 2014 02:28:18 -0700 (PDT) Received: by 10.182.132.2 with HTTP; Mon, 28 Jul 2014 02:28:18 -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 11:28:18 +0200 Message-ID: To: Pierre Joye Cc: Lonny Kapelushnik , PHP internals , Andrea Faulds Content-Type: multipart/alternative; boundary=089e011847a211425e04ff3d8bba Subject: Re: [PHP-DEV] [RFC] imagettf* deprecation/removal From: nikita.ppv@gmail.com (Nikita Popov) --089e011847a211425e04ff3d8bba Content-Type: text/plain; charset=UTF-8 On Mon, Jul 28, 2014 at 9: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. > 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 --089e011847a211425e04ff3d8bba--