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 internals+get-125212@lists.php.net to get a copy of this message
On Sun, Aug 25, 2024, 9:06 AM John Coggeshall <john@coggeshall.org> wrote: > > > On Aug 24 2024, at 12:49 pm, Bilge <bilge@scriptfusion.com> 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 . > > >

« previous php.internals (#125212) next »