On Mon, Aug 26, 2024 at 3:45 PM John Coggeshall <j...@coggeshall.org> wrote:
>
>
> 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.
>
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;
}
}
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.
- 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.
> 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 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.
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.
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.
Without this RFC, those are your only options.
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.
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.
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.
Again, there are a few lists going around on this thread, and I hope that
Bilge is taking notes to add to the RFC, and working with the folks who
helped him with implementation to determine what is and is not possible in
terms of the grammar so we can potentially exclude the more problematic
ones.
But let's not just say "no expressions" - I think there's been some
demonstrated value from a lot of these.
>
>
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
