On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney <[email protected]> wrote:
> You'll likely identify the increased delay in such cases. Generally speaking these sorts
> of default values don't change a ton, but it's not unlikely that you may say
> "I'd like half that delay" or "twice that delay". But a better example
> would be introducing a backoff, which might look like this:
>
>
> for ($i = 1; $i += 1 ; $i < 4) {
> $result = call_some_client($url, default * $i);
> if ($result->isSuccess()) {
> break;
> }
> }
>
>
This could, I'm sure you agree, be easily done without access to the default timeout. In fact,
the default timeout itself is entirely unnecessary to know... And I know you and I both know that
most default timeouts are ridiculously oversized anyway (e.g. 30, 60 sec) for real-world production
environments. :)
> In other words, you know that you want it to use the default, and then allow an increasing
> timeout duration between calls if it fails. For this, I don't necessarily want or need to know
> what the default is, only that I want to do _multiples_ of it in specific cases.
> Is it a universally good idea? No. Does it have use cases? Yes.
Putting aside timeouts being a bad example here IMO because almost all default timeout values are
unreasonably high, I simply don't think the use cases that are "good" come anywhere
near the potential for abuse -- especially when it comes to default being an object or other complex
type.
> > - 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.
> How exactly is this worrisome? Consider this:
> class A {
> public function __construct(private LogInterface $logger = new DefaultLogger()) { }
> }
> class ProxiedLogger implements LogInterface { ... }
> $a = new A(new ProxyLogger(default));
> If class A is programming to the LogInterface contract, the fact that it gets a
> proxied version of the default should not matter in the least. Being able to proxy like this means
> that a _consumer_ of class A does not need to know or care what the default implementation is; they
> can assume it follows the same contract, and proxy to it regardless. The upstream developer
> doesn't need to care, because they are programming to the interface, not the implementation.
> This doesn't violate the separation of concerns principle, nor covariance.
This example isn't worrisome. This one is (which I posted earlier in the thread). This patch
creates a whole new BC issue for upstream APIs that callers use when they (ab)use default :
https://gist.github.com/coogle/7c0fbb750288ebdd1feb8a5e9185ba8c
In this Gist where before I didn't have to worry about changing the default value breaking
downstream code (as long as the signature didn't change), I now do have to worry about changing
the default value. This was an intentionally made example using strong typing, its even worse if the
type is mixed.
> 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 didn't say that at all. I said we should identify the ones we absolutely know will be
> problematic, and restrict those from the outset. From there, we should identify the ones that
> _might_ be problematic, and determine on a case by case basis if the risks outweigh the use cases
> before Bilge brings it to a vote.
The impression I've been getting from the conversations in this RFC is that there is no
appetite for restrictions from Bilge or the supporters of the RFC. In fact Bilge said himself "
there is no good reason, in my mind, to ever prohibit the expressiveness."
https://externals.io/message/125183#125217
So taking them at their word, it seems like that conversation is off the table. The RFC based on
this thread is an up or down vote on full-fledged expressiveness, or nothing based on what I'm
reading and I certainly won't be supporting that personally.
> But if we lock it down too tightly from the outset, expanding it, while being possible, will
> more than likely mean an RFC for every expansion, because it's unlikely somebody will do
> anything comprehensive towards opening it up in the future. I'd rather not leave some of these
> use cases as a TBD for a later RFC, because that's very likely going to mean "never".
> I DO think there are likely whole categories of expressions we can likely say "no" to
> - anything where the default represents a union type (and _mixed_ is a union type) should likely
> only allow default by itself or as a bare value on the RHS of an expression.
I think you and I are saying the same thing here - the expressions need to be restricted. I 100% do
think we would need to get into specifics as to which bucket (yes/no/maybe) though before I'd
say we totally agree :) I can say I 100% agree that union types including mixed need to be out of
this equation per my code example above. This RFC and the follow-on discussion has made explicitly
clear, however, that's not a compromise the author(s) / advocate(s) are willing to entertain.
> The argument against the feature that it expands the public API is puzzling to me, particularly
> when the only other solutions are (a) Reflection, or (b) named arguments. Named arguments _are_ part
> of the public API, as the names themselves can change. Default values can change, but, importantly,
> a change in a default value does not change the actual signature of a function. Giving the ability
> to use default gives consumers of a function a far more stable API surface,
> particularly when they do not want to change a given default value, but _do_ want to provide a more
> specific value for a later argument. Right now, if not using named arguments (e.g., because
> you're worried the argument name could change), your only other option is to use the Reflection
> API, which is more expensive, introduces a whole set of other possible runtime issues, and is far
> more convoluted to achieve.
I would argue the convolution is a feature, not a bug. The code example I provided in the gist above
explains why I think it's an expansion of access into the API signature (specifically with
union types). I of course concede named parameters also were an expansion of access into the API
signature. These two things are not the same thing though in any other regard -- one had very clear
wins and benefits (named parameters), this one feels more like syntax sugar that can be easily
abused if left as a free-ranging expression.
> Had this been only to allow the default keyword, I don't think we'd be
> having this discussion at all; I think it would be pretty self-evident that there's a need, and
> a lot of folks would be happy to sign on.
I agree.
> But the author took it a step further, and asked, "What if ...?", and as such, the
> RFC provides additional benefits beyond giving you a keyword for using the default value, as it
> expands to allowing expressions. This gives a tremendous amount of flexibility and power, and solves
> some additional issues some of us have noticed.
and now there is a judgement call being made between these "additional benefits" (and I
100% concede there is an upside), and the costs. As presented IMO we've fallen far short of
that being a winning proposition for PHP in part because it provides so much flexibility and power
it starts feeling akin to introducing a new syntax to access private members of objects from outside
those objects. Again, the issue being it is being proposed as a first-class citizen in terms of
expression usage.
> So I'd argue that what we need to weigh now is which of these expressions are truly
> benefits, which ones are side effects we can live with, and which will raise new problems we do not
> want to deal with.
> But let's not just say "no expressions" - I think there's been some
> demonstrated value from a lot of these.
Honest to god I don't think I've read from one person to come out and say "no
expressions". I've personally made a number of suggestions on expression limitations that
may or may not be a good idea, such as:
https://externals.io/message/125183#125237
The problem is the RFC author has stated multiple times in their view that the expressions supported
must be exhaustive and hasn't be willing to hear valid concerns to that.
Coogle