Re: [RFC] Default expression

From: Date: Sun, 25 Aug 2024 14:33:12 +0000
Subject: Re: [RFC] Default expression
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Sun, Aug 25, 2024, 9:06 AM John Coggeshall <[email protected]> wrote:

>
>
> On Aug 24 2024, at 12:49 pm, Bilge <[email protected]> wrote:
>
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression.
> I
> think some of you might enjoy this one. Hit me with any feedback.
>
>
> Seems like you are missing an option for your theme example, which would
> be to simply extend the Config  class?
>
> While I can see the value in the concept of default , I think it's a
> mistake to allow default  to be used as a generic operand as shown in the
> RFC appendix. It seems to me that the whole point of something like
> default  is to not have to worry about what the upstream API wanted for
> that value, but the second you start allowing operations where default
> is an operand you've reintroduced the problem you were trying to avoid if
> the upstream API were to change the type of what default  ultimately
> resolves to. Worse actually because now I have no idea what default  is
> when I read code without having to dig up the upstream API.
>

If the underlying API changes the argument type, consumers will have an
issue regardless. For those cases where the expression is simply default,
you'd actually be protected from the API change, which is a net benefit
already.

This also protects the user from changes in the argument names.


> Other thoughts here are what happens when default  resolves to an object
> or enumeration or something complex? Your original example had CuteTheme ,
> so can you call a method of default ?? I could entirely see someone doing
> something like this for example:
>
> enum Foo:string {
>     // cases
>
>     public function buildSomeValidBasedOnCase(): int { // ... }
> }
>
> F(MyClass::makeBasedOnValue(default->buildSomeValidBasedOnCase()))
>
> IMO most operators listed in the appendix should be disallowed. I can see
> the value of default | JSON_PRETTY_PRINT,  but I am pretty strongly
> opposed to the idea of introducing a "conditional based on the default
> value of an upstream API call" concept of default >=1 .
>
>
>


Thread (101 messages)

« previous php.internals (#125212) next »