On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <[email protected]> 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.