Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106024 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74018 invoked from network); 22 Jun 2019 13:26:25 -0000 Received: from unknown (HELO mail-ed1-f45.google.com) (209.85.208.45) by pb1.pair.com with SMTP; 22 Jun 2019 13:26:25 -0000 Received: by mail-ed1-f45.google.com with SMTP id r12so13988120edo.5 for ; Sat, 22 Jun 2019 03:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vRA98C4bz07O27Et/u0Q8r8rAU4NApvuskqM/M3C7QY=; b=uus2xz0ypEeBjlebrKTVsFogJAv0FV7Go6jdhJJ/LxT4wtssnyX9LvCWaK/mt8+T1V Hxi6qKiIhCbHD6lX1GbXxmsNZ5AswgnUvIJfm7egQ7lc+eJLqp/XCajcX8b+2nMARrWH DTRyaMa71o0XmtoZ1TxgGFL14dewBowm15Zw3smheS/XnI7L7A8YizhpNMZFizvRasbK nlx6cHDJfbFpmSECsj53QtVtHM7EgY89x5Cj3gUZQW6o3DTb1MDmGbly98wCxQKnnQaG 6T51YA+H1mzR2YUMXS3ff11kDNMnKN7XKkVT9c58Of4ouKUXG/gAYZo87qab7vtZyh2Z O7NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vRA98C4bz07O27Et/u0Q8r8rAU4NApvuskqM/M3C7QY=; b=XwAtvouTeF/85+bBVIZ1ehzhnHg5c0Ox0TA9FnTGfr6RwfcIu1OyataX5jud5oViuN uqjX7jr+fQZlrQ6pS5SGIBl27M8KrbwFfTFnnjtIIgnlG+wSNHDK/G6wpAwgyVyG3IGs +9Ooe5GCLMpmmiv0wRC19MSfBZjKTb1QxibnkCaUuc8K7F+IZJniG2mBODz/o48iW3kl fTRgoPg4R6UQuNfwJnGcqIbmpne4f90EUC3ISj8GndOpb3DTHqtLDqb3/pS369i8xi95 QKsB52yDlg9OcPWo0d88bodiuC53SvW/iaxppC6p7jS8mMFN93oNPKK8sylCYgD07UzS oJyQ== X-Gm-Message-State: APjAAAXEJY0kyR081nfiOteaviSGSvGVHAKl8fYLGvMjwBt6wxg0rYQ+ 0pzXW55KPx8Y8F4kj1B5rIw= X-Google-Smtp-Source: APXvYqxspnaiVItbWY3RPHgdtOLLyQkqMPoaNfM3/Q6ZvUw8vHutsB7dOsziYn6//5jeShSQBgh9rg== X-Received: by 2002:a50:9282:: with SMTP id k2mr103593807eda.269.1561200107318; Sat, 22 Jun 2019 03:41:47 -0700 (PDT) Received: from [192.168.0.63] (84-75-30-51.dclient.hispeed.ch. [84.75.30.51]) by smtp.gmail.com with ESMTPSA id r12sm1686782eda.39.2019.06.22.03.41.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 03:41:46 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_C93839F4-464D-4AB7-AEF7-959C9B29D177" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 22 Jun 2019 12:41:45 +0200 In-Reply-To: Cc: Stanislav Malyshev , Internals , Nikita Popov To: Kalle Sommer Nielsen References: <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4 From: claude.pache@gmail.com (Claude Pache) --Apple-Mail=_C93839F4-464D-4AB7-AEF7-959C9B29D177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Le 22 juin 2019 =C3=A0 09:22, Kalle Sommer Nielsen a = =C3=A9crit : >=20 > Hi > Den l=C3=B8r. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev = : >> My first question for many of those is - why? I.e. it deprecates a = bunch >> of niche functions. Most people do not use these functions, so they >> probably don't care. Those they do use them would find their code = broken >> or produce new warnings and needs to be changed. I have hard time >> identifying whose life would be made better by these changes. >>=20 >> Now, if some of these functions are hopelessly broken or have no = valid >> use cases - like magic quotes - then phasing them out makes sense, = and >> the audience whose life can be made better are people who use those >> unaware of them being broken, or plan to use them and would thus have >> broken code unless we warn them (or remove the functions, = eventually). >>=20 >> But for functions that work just fine, I see absolutely no reason to >> introduce friction without any apparent upside. >=20 > While I understand where you are coming from on this, I do think that > functionality that is better supported by dedicated extensions to do > the job instead of providing some functions in the standard library > that converts from a few specific encodings to another: >=20 > convert_cyr_string() -- This uses a non standard set of encoding names > and only for cyrillic like encodings, what justifications is there for > keeping this in the standard library over using ext/intl with > UConverter that supports a much larger set of encodings in a much more > generic way for more than just cyrillic encodings? >=20 > hebrev(), hebrevc() -- These functions were designed for the web era > pre IE6 where some browsers did not support lang=3D"he">, what use case is there for these now that the web has > evolved so much in the past two decades since these were added to do > this on a backend? >=20 > One of the biggest complaints we have in regards to the standard > library is that it is inconsistent, it provides very niche > functionality that is better supported elsewhere. I think it is a > perfect opportunity to review these legacy blocks and direct users to > better alternatives instead of us having to support many ways of doing > the same thing. Why should the standard library support only a subset > of conversion functionality that is so niche and already supported > much more fluently and abstract in extensions dedicated for the > matter. I personally think that is a very valid reason to consider > these functions for deprecations. >=20 > We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical > depth as a side-effect. The cost of having to convert these functions > is a small price to allow the language to evolve in my honest opinion. >=20 PHP has indeed a sheer number of old-school functions and of niche = functions, but as developer, they don=E2=80=99t bother me as long as I = don=E2=80=99t see them. One occasion where I am bothered, because I see them, is when I explore = the manual in order to find a function that does some job. Let=E2=80=99s = take for example the Session Functions: https://www.php.net/manual/en/ref.session.php = In the Table of Contents, functions that are actually useful (e.g., = `session_start()`) are intermixed with legacy functions that relate to = some obsolete way to handle session variables (e.g. = `session_register()`). For the particular case of Session functions, there is *some* progress = since few years ago (the days of PHP 5.2), because obsolete functions = are clearly marked as such on their individual documentation page = (https://www.php.net/manual/en/function.session-register.php = ; although = the pink Warning box ought to be at the very top of the page, so I=E2=80=99= m not in danger to actually read the documentation before realising that = it is obsolete). But the Table of Contents still needs to be = reorganised... Now, let=E2=80=99s take the manual of String Functions: https://www.php.net/manual/en/ref.strings.php = Those may be separated in two groups: the first one for those that are = recommended/useful for modern code, and the second one for legacy = functions such as `convert_cyr_string()` and `hebrevc()` that provide = functionality that are hardly useful today or that are better handled by = some other mean. Moreover, for each of those functions, a pink Warning box might be = placed at the very top of their documentation page, stating that such = function is probably not useful or recommended for new or refactored = code, and pointing to better alternatives when appropriate. *However*, such documentation improvement, does *not* imply throwing a = deprecation warning each time the functionality is used. There is no = issue for legacy code base to continue to use it as long as it is not = broken, and as long as I don=E2=80=99t see it. =E2=80=94Claude --Apple-Mail=_C93839F4-464D-4AB7-AEF7-959C9B29D177--