Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106033 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60556 invoked from network); 22 Jun 2019 22:15:59 -0000 Received: from unknown (HELO mail-pf1-f170.google.com) (209.85.210.170) by pb1.pair.com with SMTP; 22 Jun 2019 22:15:59 -0000 Received: by mail-pf1-f170.google.com with SMTP id q10so5254380pff.9 for ; Sat, 22 Jun 2019 12:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6uroIkMe8AwUxoMLjNpZxkYES+YaS2h/HQ9lZCQyzvU=; b=dh2bZJEXOddXxXGsJFrNQJOzRI5BzCViD/XjbFnH7+g9O+iF0Q/RwQxQ1X5ssk1+EC XSMgRNehPqlWsJDyk4oKEDSo0j2vj+wibI05m+pSa5NJpmsLrY1ZCnAn8XN5TxfzluRF qRDaCdEkANsatvsYTv/+4T/0V7tjG424S/YcS5j34m+W3Yw2Xa6KxIcy4jq8G3H3Lfkm r7N3tQji0sQUKyzr1oF94Ky16yKfSN+vFx1hrFVK1ZHH2EQxPvWwdmrEFn1iAOxToXLE 1mkZmj/6QY4MC6meroW13hPstBRYM1nTLGsNODVHRRmP18IE46x9V6rQD49pJ5N49bz6 yDSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6uroIkMe8AwUxoMLjNpZxkYES+YaS2h/HQ9lZCQyzvU=; b=QpyYeiG9AeGw6MAwtwPHr7qHf7RIyBig9b7zmcJXI5xn5tqn4hLoGZRy0uP2arsdtM EkhzyvTNxf52G/+Ip7lJYLNejP4HitgE+Csv8yDLjxqM96UivKkp2a0fvYq8T5LHayac 9gvLxqNZhYhcVFIchef7Qs9Rz3zb2DdPQfm5XDQWrexuJ55xCeHgL9p0d+WLJyV48efO 8t2VEVc05p3tZml1wCeSt0tNYezB/urbgFoAwAqzqGfFiOHQ5wMKXIFU7FWCQKufcuop cAhvN/xDThGHn794I/Tk/XE297e0wG0bWpAz7v+TaNzx30XDjcr65VFmMatwtrNZFnuX 70sQ== X-Gm-Message-State: APjAAAVodmHZbExOEnBemdMGPi6xbgSHFD8M+8uuoOEjn6ZYYLCGpBea 8fKmGHiOkNNzgNSKIiCF6w== X-Google-Smtp-Source: APXvYqwHmJwyL6jG+Sr5VekhQNkL41jp6QAXbaxaPVBclor6jmTzvehswxWx7n2OyTZ4XwoeRcJgjA== X-Received: by 2002:a17:90a:d814:: with SMTP id a20mr14763366pjv.48.1561231886631; Sat, 22 Jun 2019 12:31:26 -0700 (PDT) Received: from Stas-Pro-2016.lan (c-24-4-176-254.hsd1.ca.comcast.net. [24.4.176.254]) by smtp.gmail.com with ESMTPSA id v28sm6133495pga.65.2019.06.22.12.31.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 12:31:25 -0700 (PDT) To: Kalle Sommer Nielsen Cc: Internals , Nikita Popov References: <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> Openpgp: preference=signencrypt Autocrypt: addr=smalyshev@gmail.com; prefer-encrypt=mutual; keydata= mQMuBE9mqaARCACFSqcGmNunkjQQu3X+yXnTmFeEkvM4JXZTOBdR8aEevNGmmFEfyvjaDjWi 9hcwp4E/lYtC+P7VsVjM1OSX9eq0jC/lGL0ZyRXek+mNy0n5H1NSuTpf9Y18LMqhc4G+RU+L cNiZ9K0DJuOOvNLPxW7OHZguxb3wdKPXNVa2jyRfJAKm2uaJJMT1mTmFT9a0Q8SKr+mUrrJk uG0H2o6SzrKt8Wwoint1eh67zVsJaJtQFchnEZnlawIcqP2yC4nLGR3MkubowxoEBYCZet18 aHVVRbvpG2Qtob8Lu5xrsGbmXymTkHTdpvkfcJFADa8MzOL90zOxXwbGfbIZOlh5En8jAQCX lfnx2eQL3BSW/6XANa51dbWiEp1d1BAkpGKtZvlk0Qf+M9WAi+9aXMe3xP5krxtgnRNUf2WN 6Zdy2MxL1RRJCFbytLhl0ronC49BsGYVGshdEH8xhBbiIOJKuVZ/DTl9bEm7P9c7CC7iJyVC khUAhouH6xzZQNLR+RU+QebYzXypVfl99Qk7EdMmr/WAZCHLuvanyqepC5EBsa3VnAfQemSN oBeGBKWWLiOsPjvS72+y1z4RUMAfXHn4l/sFMt8zt7/74AmJPwZquV41p4mPO12V4+xPyc6R sB84sfsk2QVivU8w8AkvGQeYjXoz7Iwao95+fWteVzZ36KRQvUckP8pGjHlDXnHxJ0HI1I/k OBZSjwRwUf0dd73y6erPhbLk+gf+NdI3H9KGJBzG5/rVyWKwUeQ9d5ud4jTJRkQGvAP5pg76 vEa9dogbpe4W5Z+0BfbiJSnQmQWSHiZddj/t33ptbup44Ck6ZTgdlmFYMLF1hR47PIZTDKER EuKYGci/vq8snZvEJP9YCw/TtiHcMdrMKcY/+Lp8lQO0GHLPB9glVhnC0db6l1Xpg1CMI8/R ozBMcij30EgATggC/y2zbiqAFoS9FN9nXPbe4phStqABEyeZ+nXudt7PUYTjVgcrqo8bHZCi sBobWC7OnKyUzxVxzUeuPkIfmZuzkLaMw2McQdvwwsNvQ0DzaLP30c1Xsm/7EIYJcOWpzlVJ 5QrdmE0/BbQyU3RhbmlzbGF2IE1hbHlzaGV2IChQSFAga2V5KSA8c21hbHlzaGV2QGdtYWls LmNvbT6IegQTEQgAIgUCT2aqtAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQL3lW vF2gS12XMwD9HuRIolSwIK77u8EY461y2u6sbX36n5/uo/LDQuxoi3sA/0MvpnvzOhv9Iufv vsZEj3E7i3h+iD5648YMwfTFCij+uQINBE9mqaAQCADfZPMpjZkkGZj3BY/7ApoLq4mwqzbh +CpLXwNn20tFNvSXfb8RdeXvVEb7Scx+W9qYpiaun2iXJgCVH8fgpZpR856ulT1q6uCG++CX ubEvip/eJkZl93/84h04KQJwsgOrAh0Om3OePRn8Pr+++0LNS0EL8uX/YHeTOGOnnmTqYTey SBVFdov6L4mepddfjekicKQqhL7mZh/xuq29JijT0uNNX8v4vDWQDu5dlAcdd+uB3gcXMD/P ginD11zp+6wtrWCm/+yBqpvDwXQX5PGUnwvbRfl7Ay3MmwmoXiecZMg0dwTSc7e0lhB4HGRH ZdBMJB4rHUVGdzqujK/ctOvrAAMFB/0Utb76Qe6sCMlHxVAmeE/fbo7Pi05btZ/x01r67dHf aMSP0riCKJ7M0OW+jAXtu9+z/BVnYisW67WWfxl2cS5tZDgiHgJARXWUOO72+sScHP8KQmTl 1z16gyKbwY3SmyBkwcpOL35nhUWNLy93syPoY6sZUTikr2bZYukHDQ33XBPs4e6MbWKfsa9q aVmnlOF3k5UqChjutfHaEa4Q7VP4wBIpphHBi9MI16oJIzzBPbGl2uoedjwiZ6QeQZnSuOVY ZxU2d3lRA8PrtfFN1VSlpEm/VcAvtieHUYWHN0wOu+cp3Slr5XJVNjTjJhl28SlinMME54mK AGf2Ldr/dRwXiGEEGBEIAAkFAk9mqaACGwwACgkQL3lWvF2gS126EQD/VVd3FgjLKglClRQP zdfU847tqDK4zJjbmRv5vLLwoE0A+wbrQs7jVGU3NrS0AIl5vUmewpp2BKzSkepy23nWmejw Message-ID: <0d8eae42-0650-53d9-3436-25611e2f5da6@gmail.com> Date: Sat, 22 Jun 2019 12:31:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4 From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > 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: It may be supported by other extensions (btw did anybody verify that it actually is and gives the same results?), but this is not the reason per se to remove old working functions. There's a lot of duplication in programming languages - all (Turing-complete) languages ultimately do the same thing, and most practical languages have way more syntax and utility functions than strictly necessary to achieve desired outcome. This is because redundancy in expressiveness improves productivity. Here we have the reverse - we are forcing people who have working code to go back and rewrite it to essentially achieve the same result we already have - negative productivity. I don't see a point in doing this. > 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 It works. > hebrev(), hebrevc() -- These functions were designed for the web era > pre IE6 where some browsers did not support lang="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? I see multiple references to it in code online. If it works for people that use it - why touch it? I even see porting it to other languages, like Javascript. Pretty weird for a function that nobody ever needs, isn't it? > 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 I don't see it as a complaint at all. "Library provides many functions" - this is a *complaint*?! This is pretty much why PHP became popular! I know there are people online that enjoy writing nitpicky snide articles about how PHP is "inconsistent". I say - let them. Internet is big, anybody can write anything, it's not a reason to take to heart everything random people on the internet write. Satisfying those people - some of whom aren't even PHP users - is infinitely less important than the time of actual PHP users that actually use the language. And I do not see who of the actual PHP users these removals would help. "Consistency" is only helpful when it improves something and makes work easier. Nothing is made easier by removing functions that work. > 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. It is very common in virtually all programming languages to have utility functions to support special cases, even if there's a library that supports more generic case. You have your regular expression library, and then you have functions that parse dates, or numbers, or phone numbers - even though regex library alone enough to implement those. It is a very common and standard practice. Moreover, we're not talking about introducing new functionality here - we're talking about removing functionality that people *already use in their code*. The bar for this should be super-high. In fact, excluding clear blunders like magic quotes, etc. if we never ever removed a working function, I'd be fine even with that. But if we decide to remove, it should be for reasons far better than "you can do it with other functions" - that never was the PHP way and shouldn't be. > We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical What you call "convoluted" I call "convenient and versatile". Having many functions to help people do what they need is good. We don't pay per function. There's no goal to have as few functions as possible. > 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. I don't see how this is "evolving", if you understand evolving as getting more fit for the purpose. I do not recognize "having as few functions as possible" as a goal worth pursuing, so what's the point? -- Stas Malyshev smalyshev@gmail.com