Hey Ilija. On 11.03.22 18:13, Ilija Tovilo wrote:
Hi everyoneIt's been a while. Hope you are doing well. Last year I sent an e-mail to the mailing about the current state of string interpolation in PHP. I have now created an RFC to better explain the current behavior and why it would make sense to deprecate/remove some of it. https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation Previous thread: https://externals.io/message/111519 Let me know what you think.
As I already stated on twitter[1] for me there are multiple things missing:First of all it would make it much easier for me to see what impact this RFC has if there were any numbers in it of how many large-scale repositories on for example github are affected by this.
But on the other hand, and that's much more important to me, I am missing the part where you explain the concrete benefits of that deprecation for the evolution of the language.
In evolution everything is fine as it is unless it directly hinders the forthcoming and development of new essential features. IN PHP that means - at least for me - as long as something is not in the way of a new feature or a strategy we leave it as it is.
Deprecating something in terms of raising a deprecation message in the error log, means that something is going to go away in one of the next versions. We are going to remove a feature because we have a strategy to improve something in that part. Be it complexity in the source code or replacing a functionality or speeding up the language.
But so far I can see none of these things to apply here. The only argument that you are giving in the RFC are that they are "rarely useful" (reminds me a bit of Jack Sparrows "Ah! But you have heard of me") and that they are easily confused.
While the later argument would also speak for unifying the needle/haystack parameter order it is also making an assumption. Which is not backed by any statistics. How many bug reports do we have in the bug tracker due to this "confusion"?
Also what is "useful" is always a rather subjective matter. Just because I don't find feature X useful doesn't mean that others can't find it useful.
But what worries me the most is that your proposal to deprecate and essentially remove some string features that have been in the language for quite some time and have once been considered relevant is not giving me an idea of how that will benefit the language itself. How that will immediately allow us to improve the language. By either removing 20% of code that we suddenly don't need to maintain any more or because it will allow us to immediately implement feature X in PHP9.
And just removing something to allow a different RFC that "might" allow proposing other stuff is premature optimization. We might be able to need this feature, so let's tweak our code for that possibility right now. Without knowing whether that might actually be happening. And we should not remove features *now* just because someone at one point in a future might want to do something.
So while I appreciate the idea of a cleaner API I will for sure vote "no" on this RFC in it's current form.
My 0.02€ Cheers Andreas [1] https://twitter.com/heiglandreas/status/1502338172210065409 -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
