On Aug 24 2024, at 12:49 pm, Bilge <bi...@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.
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 .
