Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125378
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 1 Sep 2024 14:22:25 -0600
Message-ID: <CA+JpajnHL4VTWx4y6yCK7H3Mm=RpvHF05y3Cf4OkmzdFsS5CPA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Default Expression
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d397950621149500"
From: hamiegold@gmail.com (Hammed Ajao)

--000000000000d397950621149500
Content-Type: text/plain; charset="UTF-8"

Hi all,

I've been following the discussion on the Default Expression RFC, and while
I appreciate the effort to introduce more flexibility in handling default
values, I have some significant concerns about this proposal. I'd like to
share my thoughts and invite further discussion.

1. Complexity vs. Benefit:
   The proposed `default` expression adds considerable complexity to PHP's
syntax. While it might solve some edge cases, I'm not convinced the
benefits outweigh the added complexity. Our current methods (named
arguments, null coalescing, etc.) already handle most scenarios effectively.

2. Principle of Least Astonishment:
   PHP developers are used to default values being implicitly used when
arguments are omitted. Introducing an explicit `default` keyword changes
this expectation and could lead to confusion, especially for newcomers to
the language.

3. Type Safety and LSP:
   The ability to modify default values at the call site raises concerns
about type safety. The RFC's example of potential LSP violations is
particularly worrying. This could lead to subtle bugs that are hard to
track down.

4. Code Readability:
   One of PHP's strengths is its readability. I'm concerned that `default`
expressions, especially when combined with other operations, could make
code harder to understand at a glance.

5. Performance Considerations:
   The RFC mentions using reflection-like mechanisms for `default`. Have we
considered the performance implications, especially for high-traffic
applications?

6. Inconsistent Behavior:
   The proposal suggests different behaviors for `default` in various
contexts (e.g., function arguments vs. variadic args vs match expressions).
This inconsistency could be a source of bugs and confusion.

7. Maintenance Burden:
   Implementing and maintaining this feature, with all its proposed
restrictions and edge cases, seems like it would add a significant burden
to the language maintainers.

8. Backward Compatibility:
   While the RFC claims no known BC breaks, changing the meaning of
`default` in certain contexts could potentially cause subtle issues in
existing codebases.

I understand the motivation behind this RFC, but I'm concerned that it's
solving a problem we don't really have, while introducing new ones. Perhaps
we could explore alternative ways to address the specific use cases that
motivated this proposal?

For example, the `applyTheme` function in the proposal can be simply
implemented as:

```php
function applyTheme(?string $theme = null) {
    return new Config(...(isset($theme) ? [new $theme] : []));
}
```

This achieves the same result without having to call `array_filter` or rely
on reflection, and without introducing a new language construct.

What do others think? Am I overlooking some key benefits that would justify
these concerns?

Looking forward to hearing your thoughts,

Cheers,
Hammed

--000000000000d397950621149500
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"gmail-whitespace-pre-wrap gmail-break-words">H=
i all,<br><br>I&#39;ve been following the discussion on the Default Express=
ion RFC, and while I appreciate the effort to introduce more flexibility in=
 handling default values, I have some significant concerns about this propo=
sal. I&#39;d like to share my thoughts and invite further discussion.<br><b=
r>1. Complexity vs. Benefit:<br>=C2=A0 =C2=A0The proposed `default` express=
ion adds considerable complexity to PHP&#39;s syntax. While it might solve =
some edge cases, I&#39;m not convinced the benefits outweigh the added comp=
lexity. Our current methods (named arguments, null coalescing, etc.) alread=
y handle most scenarios effectively.<br><br>2. Principle of Least Astonishm=
ent:<br>=C2=A0 =C2=A0PHP developers are used to default values being implic=
itly used when arguments are omitted. Introducing an explicit `default` key=
word changes this expectation and could lead to confusion, especially for n=
ewcomers to the language.<br><br>3. Type Safety and LSP:<br>=C2=A0 =C2=A0Th=
e ability to modify default values at the call site raises concerns about t=
ype safety. The RFC&#39;s example of potential LSP violations is particular=
ly worrying. This could lead to subtle bugs that are hard to track down.<br=
><br>4. Code Readability:<br>=C2=A0 =C2=A0One of PHP&#39;s strengths is its=
 readability. I&#39;m concerned that `default` expressions, especially when=
 combined with other operations, could make code harder to understand at a =
glance.<br><br>5. Performance Considerations:<br>=C2=A0 =C2=A0The RFC menti=
ons using reflection-like mechanisms for `default`. Have we considered the =
performance implications, especially for high-traffic applications?<br><br>=
6. Inconsistent Behavior:<br>=C2=A0 =C2=A0The proposal suggests different b=
ehaviors for `default` in various contexts (e.g., function arguments vs. va=
riadic args vs match expressions). This inconsistency could be a source of =
bugs and confusion.<br><br>7. Maintenance Burden:<br>=C2=A0 =C2=A0Implement=
ing and maintaining this feature, with all its proposed restrictions and ed=
ge cases, seems like it would add a significant burden to the language main=
tainers.<br><br>8. Backward Compatibility:<br>=C2=A0 =C2=A0While the RFC cl=
aims no known BC breaks, changing the meaning of `default` in certain conte=
xts could potentially cause subtle issues in existing codebases.<br><br>I u=
nderstand the motivation behind this RFC, but I&#39;m concerned that it&#39=
;s solving a problem we don&#39;t really have, while introducing new ones. =
Perhaps we could explore alternative ways to address the specific use cases=
 that motivated this proposal?<br><br>For example, the `applyTheme` functio=
n in the proposal can be simply implemented as:<br><br>```php<br>function a=
pplyTheme(?string $theme =3D null) {<br>=C2=A0 =C2=A0 return new Config(...=
(isset($theme) ? [new $theme] : []));<br>}<br>```<br><br>This achieves the =
same result without having to call `array_filter` or rely on reflection, an=
d without introducing a new language construct.<br><br>What do others think=
? Am I overlooking some key benefits that would justify these concerns?<br>=
<br>Looking forward to hearing your thoughts,<br><br>Cheers,<br>Hammed</p><=
/div>

--000000000000d397950621149500--