On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <mweierophin...@gmail.com> wrote: > > I can see a few others: > > - string concatenation. I might want to prepend or append a string to a > default. > > - fractional or multiplicative application, e.g. for durations/timeouts. > These might require testing for non-zero first as well.
I have to be honest all of these both sound like really bad practices. Maybe I'm just not being imaginative enough... but if you don't control the upstream library why would you ever trust it like that? Writing a timeout default * 0.5 when default is 1000 is a really bad way to set your timeout to 500 -- because next time you done a composer update suddenly the upstream package set the timeout to 5000 and now instead of 500 your timeout has silently become 2500. > - decorating a default instance (e.g. to lazily create a proxy without > knowing the default implementation used for an argument hinted against an > interface) This is exactly the usage I'm highlighted as problematic in my code example. You're introducing a new worry for the upstream API developer that doesn't need to exist, and violating a separation principle that has existed in PHP since default parameters were created 25+ years ago. > IF it's possible to accomplish, I think it's better to identify the "leaving > this open will create WTF situations" than to prematurely lock _everything_ > down up front. If this feature is released with an overly broad scope in terms of expressions, etc. it's not like we can take it back at that point because now people are using it in unknown ways. It is not one I'm comfortable with a "let's move forward and see what happens" approach. I don't think this RFC is anywhere near a state of being ready for a vote and I'd like to see it go back and be updated with all this feedback before we continue going back and forth on the mailing list about it. This isn't a small feature, despite the fact on the surface it seems relatively minor as compared to other things. It is introducing a whole new concept into PHP of, at least in some circumstances, suddenly making the default parameter in a function signature a formal part of it and of utmost importance that API developers have to think about changing. It's a big deal. Offhand, I am unaware of what other languages have done this or allow anything like it (are there any?) -- and there have been demonstrated real concerns backed with code examples of how this becomes problematic. Not to mention the fact it would retroactively make all default parameters in all PHP code suddenly accessible by downstream consumers in a way the author simply never intended for. As others have mentioned, this is just as big of a deal as if there was an RFC that suddenly gave developers a syntax to access object's private methods by adding ! to the property name or something (e.g. an RFC that proposed accessing private members of an object just by doing $foo->myPrivate! ). I am being left with the impression based on these emails that those in favor of this are hand-waving past some very legitimate concerns trying to push it through, rather than taking the appropriate action of accepting the feedback in the collaborative fashion it was intended and going back to the RFC to address those concerns fully. Perhaps that impression is mistaken, and if so I apologize... But to be clear I don't think there is anywhere near enough consensus on this RFC to make this a slam dunk, nor do I think it's a few tweaks away from being adoptable.
