Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76203
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CB8034ED-00AA-4FCA-B368-61E579F9D0C8@lonnylot.com>
References: <482DEC36-8A5A-4840-910A-3C63CA3A503B@lonnylot.com>
	<B2A0452A-354A-4733-A3D7-0E8ABE61DAC6@ajf.me>
	<CAEZPtU7HQ5Y-h_36pTBb_2NMZfo=UEzwWKHL4k630y+Jbh7XYQ@mail.gmail.com>
	<77BCF83D-F7AF-4853-8C40-D07D1CFFF8DE@lonnylot.com>
	<CAEZPtU6fuofAo7yy98qj8ijymdySukd1_5YJCc=bifLF=btasA@mail.gmail.com>
	<CB8034ED-00AA-4FCA-B368-61E579F9D0C8@lonnylot.com>
Date: Sun, 27 Jul 2014 21:30:55 +0200
Message-ID: <CAEZPtU5TMp20iTSU3=Bz7nCT_Mn7piFKyW2zr9vv=NwyzGaOSA@mail.gmail.com>
To: Lonny Kapelushnik <lonny@lonnylot.com>
Cc: PHP internals <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>
Content-Type: multipart/alternative; boundary=047d7bdc134059e84504ff31d812
Subject: Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
From: pierre.php@gmail.com (Pierre Joye)

--047d7bdc134059e84504ff31d812
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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_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=E2=80=99m sug=
gesting
E_DEPRECATED in 5.6.z+1 and removal in php.next.
>

> On Jul 27, 2014, at 1:22 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>> The API signatures are compatible, yes? In which case, just make the
legacy functions be aliases of the new ones. This avoids breaking
everyone=E2=80=99s code.
>
>
> Andrea,
>
> I don=E2=80=99t think that assessment accurately reflects the situation. =
I=E2=80=99m
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=E2=80=99m suggesting having this minor change be one of the BC breaks i=
n
php.next. I=E2=80=99m not making the argument that it is important from a p=
urely
technical POV; I don=E2=80=99t believe it is. I=E2=80=99m making the argume=
nt that it is
important from an operational POV. Removing them prevents newcomers and
gurus from ever having any question about which function to use.

--047d7bdc134059e84504ff31d812--