On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney <mweierophin...@gmail.com>
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
