Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101072
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 84.19.169.162 cause and error)
Message-ID: <1509971910.22577.22.camel@schlueters.de>
To: Michael Morris <tendoaki@gmail.com>, PHP internals
 <internals@lists.php.net>
Date: Mon, 06 Nov 2017 13:38:30 +0100
In-Reply-To: <CAEUnE0fH92RSXsGN6u0SQZL60_2J3Znr1adxweHWcEx41YRWbQ@mail.gmail.com>
References: <BF.30.09857.D9DEDF95@pb1.pair.com>
	 <9331841e-ea9a-652b-3b54-5dc24dbd273b@gmail.com>
	 <CAAfnsFU6=QwOizAhFXz9GBvsn76_y+tKMVqSS8UEz_YTJKGV0Q@mail.gmail.com>
	 <1509917800.22186.15.camel@schlueters.de>
	 <CAEUnE0fH92RSXsGN6u0SQZL60_2J3Znr1adxweHWcEx41YRWbQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Proposal: Rename image functions
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On So, 2017-11-05 at 20:18 -0500, Michael Morris wrote:

> Then, for backward compatibility, add a php.ini setting that runs
> "import PHP\Legacy" at the start of each script.

We did that mistake with magic_quotes and the ze1 compatibility mode in
PHP 5.0. We should learn from that and reduce number of ini settings
which have impact on the script behavior, not increase this. This
makes, among other things, writing portable code hard (While the
environment changed, back in the days shared hosting was a bigger
thing, while nowadays with containers users often have more control
over their environment)

*If* we do something in those areas this should always be that we
provide superb options to do stuff in a "clean" (as defined in
contemporary understanding) way, which makes the old way obsolete.
Introducing a new set of APIs without substantial gain won't get
traction (as developers have to relearn, books, tutorials, ... are
suddenly outdated, libraries have to make compatibility choices,
copy&paste-programming keeps legacy alive, ....)

As an example: If we provide a new full set of unicode aware string
manipulation, routines these might render byte-based string functions
obsolete for many use-cases and offer a gain. (how else could an
application handle emojis ... so this is nowadays is even relevant for
English-only use cases ... ?)

Or if we provide an image manipulation framework which supports higher
level constructs than pixels and lines ...

johannes