Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125379
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 1 Sep 2024 15:47:53 -0600
Message-ID: <CA+Jpajmb6vp+yLG8Z78TafrCu3ZyYFrw5PL5JFSsAeA_ZX_Jjw@mail.gmail.com>
Subject: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as Object Properties and Named Parameters in PHP
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000007a9d33062115c7c2"
From: hamiegold@gmail.com (Hammed Ajao)

--0000000000007a9d33062115c7c2
Content-Type: text/plain; charset="UTF-8"

Dear PHP internals community,
I hope this email finds you all well. I'd like to propose an idea that I
believe could enhance PHP's flexibility and consistency, especially when
working with string literals. I'm looking forward to hearing your thoughts
and feedback on this proposal.
Introduction
I'm suggesting two enhancements to PHP that I think could make our lives as
developers a bit easier:

Support for String Literals as Object Properties
Support for String Literals as Named Parameters in Function Calls

The main goal here is to reduce our reliance on arrays and provide more
intuitive ways to define and access data, particularly in scenarios like
working with HTTP headers where we often deal with non-standard characters
and strings.
1. String Literals as Object Properties
Current Situation
As we all know, we typically define and access object properties using
standard identifiers:
```php
class Foo {
    public string $contentType = "application/json";
}

$obj = new Foo();
$obj->contentType = "text/html";
```

But when we're dealing with data that includes non-standard characters or
strings (think HTTP headers), we often end up using associative arrays:
```php
$headers = [
    "Content-Type" => "application/json",
    "X-Custom-Header" => "value"
];
```

I think we can all agree that this reliance on arrays can make our code
less intuitive, especially when we're managing complex data structures.
Proposed Enhancement
What if we could use string literals as object property names? Here's what
I'm thinking:
```php
class MyHeaders {

    public function __construct(
        public string "Content-Type" = "application/json",
        public string "Cache-Control" = "no-cache, no-store,
must-revalidate",
        public string "Pragma" = "no-cache",
        public string "Expires" = "0",
        public string "X-Frame-Options" = "SAMEORIGIN",
        public string "X-XSS-Protection" = "1; mode=block",
        public string "X-Content-Type-Options" = "nosniff",
        public string "Referrer-Policy" = "strict-origin-when-cross-origin",
        public string "Access-Control-Allow-Origin" = "*",
        public string "X-Custom-Header" = "value",
    ) {}

    public static function create(string ...$headers): self {
        return new self(...$headers); // Throws an error if an unknown
named parameter is passed
    }

    public function dispatch(): void {
        foreach ((array) $this as $name => $value) {
            header("$name: $value");
        }
    }
}

$headers = new MyHeaders("Content-Type": "application/json",
"X-Custom-Header": "value");
// or
$headers = MyHeaders::create("Content-Type": "text/html; charset=utf-8",
"X-Custom-Header": "value");
$headers->dispatch();
```
This would allow us to include characters in property names that aren't
typically allowed in PHP identifiers, like hyphens or spaces. I think this
could make our code more readable and aligned with natural data
representation.
Benefits

Greater Flexibility: We could create more natural and direct
representations of data within objects.
Enhanced Consistency: This aligns with the proposed support for string
literals as named parameters, creating a more uniform language experience.
Simplification: It could reduce our need for associative arrays, which can
be more error-prone and less intuitive.

2. String Literals as Named Parameters in Function Calls
If we're going to use string literals as object properties, it makes sense
to also use them as named parameters, especially in constructors with
promoted properties. And why stop at constructors? This leads to the second
part of my proposal.
Current Situation
We can use named parameters in function calls, but only with standard
identifiers:
```php
function myHeaders(...$args) {
    foreach ($args as $key => $value) header("$key: $value");
}
```

To use string literals with special characters, we have to use associative
arrays:
```php
myHeaders(...["Content-Type" => "application/json"]);
```

This can be a bit cumbersome and less readable, especially for complex data
structures.
Proposed Enhancement
What if we could use string literals as named parameters? It might look
something like this:
```php
foo("Content-Type": "application/json");
```

I think this syntax could offer several advantages:

Improved Readability: Our code could become clearer and more aligned with
natural data representation.
Automatic Parameter Mapping: We could map string literals to corresponding
parameters without requiring manual intervention.
Simplified Constructor Usage: This could be especially beneficial for
constructors where we need to pass complex data structures directly.

Implementation Considerations
Of course, implementing these changes would require some work:

The PHP engine would need to accommodate string literals as valid property
names and named parameters, both at runtime and in class/function
definitions.
We'd need to carefully manage compatibility with existing code to ensure
traditional property access remains unaffected.
We'd need to decide whether to allow string literals as parameters in
function/method declarations or only in function calls (to be retrieved by
func_get_args() or variadic functions), with exceptions for constructors
with promoted properties.

I'm really interested to hear what you all think about this proposal. Do
you see potential benefits or challenges that I might have overlooked? How
do you think this could impact your day-to-day coding?
Looking forward to a great discussion!
Best regards,
Hammed

--0000000000007a9d33062115c7c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear PHP internals community,<br>I hope this email finds y=
ou all well. I&#39;d like to propose an idea that I believe could enhance P=
HP&#39;s flexibility and consistency, especially when working with string l=
iterals. I&#39;m looking forward to hearing your thoughts and feedback on t=
his proposal.<br>Introduction<br>I&#39;m suggesting two enhancements to PHP=
 that I think could make our lives as developers a bit easier:<br><br>Suppo=
rt for String Literals as Object Properties<br>Support for String Literals =
as Named Parameters in Function Calls<br><br>The main goal here is to reduc=
e our reliance on arrays and provide more intuitive ways to define and acce=
ss data, particularly in scenarios like working with HTTP headers where we =
often deal with non-standard characters and strings.<br>1. String Literals =
as Object Properties<br>Current Situation<br>As we all know, we typically d=
efine and access object properties using standard identifiers:<br>```php<br=
>class Foo {<br>=C2=A0 =C2=A0 public string $contentType =3D &quot;applicat=
ion/json&quot;;<br>}<br><br>$obj =3D new Foo();<br>$obj-&gt;contentType =3D=
 &quot;text/html&quot;;<br>```<br><br>But when we&#39;re dealing with data =
that includes non-standard characters or strings (think HTTP headers), we o=
ften end up using associative arrays:<br>```php<br>$headers =3D [<br>=C2=A0=
 =C2=A0 &quot;Content-Type&quot; =3D&gt; &quot;application/json&quot;,<br>=
=C2=A0 =C2=A0 &quot;X-Custom-Header&quot; =3D&gt; &quot;value&quot;<br>];<b=
r>```<br><br>I think we can all agree that this reliance on arrays can make=
 our code less intuitive, especially when we&#39;re managing complex data s=
tructures.<br>Proposed Enhancement<br>What if we could use string literals =
as object property names? Here&#39;s what I&#39;m thinking:<br>```php<br>cl=
ass MyHeaders {<br><br>=C2=A0 =C2=A0 public function __construct(<br>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 public string &quot;Content-Type&quot; =3D &quot;appl=
ication/json&quot;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string &quot;Cach=
e-Control&quot; =3D &quot;no-cache, no-store, must-revalidate&quot;,<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 public string &quot;Pragma&quot; =3D &quot;no-cach=
e&quot;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string &quot;Expires&quot; =
=3D &quot;0&quot;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string &quot;X-Fra=
me-Options&quot; =3D &quot;SAMEORIGIN&quot;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 public string &quot;X-XSS-Protection&quot; =3D &quot;1; mode=3Dblock&quot;=
,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string &quot;X-Content-Type-Options=
&quot; =3D &quot;nosniff&quot;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public strin=
g &quot;Referrer-Policy&quot; =3D &quot;strict-origin-when-cross-origin&quo=
t;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string &quot;Access-Control-Allow=
-Origin&quot; =3D &quot;*&quot;,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public stri=
ng &quot;X-Custom-Header&quot; =3D &quot;value&quot;,<br>=C2=A0 =C2=A0 ) {}=
<br><br>=C2=A0 =C2=A0 public static function create(string ...$headers): se=
lf {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return new self(...$headers); // Throws=
 an error if an unknown named parameter is passed<br>=C2=A0 =C2=A0 }<br><br=
>=C2=A0 =C2=A0 public function dispatch(): void {<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 foreach ((array) $this as $name =3D&gt; $value) {<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 header(&quot;$name: $value&quot;);<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }<br>=C2=A0 =C2=A0 }<br>}<br><br>$headers =3D new MyHe=
aders(&quot;Content-Type&quot;: &quot;application/json&quot;, &quot;X-Custo=
m-Header&quot;: &quot;value&quot;);<br>// or<br>$headers =3D MyHeaders::cre=
ate(&quot;Content-Type&quot;: &quot;text/html; charset=3Dutf-8&quot;, &quot=
;X-Custom-Header&quot;: &quot;value&quot;);<br>$headers-&gt;dispatch();<br>=
```<br>This would allow us to include characters in property names that are=
n&#39;t typically allowed in PHP identifiers, like hyphens or spaces. I thi=
nk this could make our code more readable and aligned with natural data rep=
resentation.<br>Benefits<br><br>Greater Flexibility: We could create more n=
atural and direct representations of data within objects.<br>Enhanced Consi=
stency: This aligns with the proposed support for string literals as named =
parameters, creating a more uniform language experience.<br>Simplification:=
 It could reduce our need for associative arrays, which can be more error-p=
rone and less intuitive.<br><br>2. String Literals as Named Parameters in F=
unction Calls<br>If we&#39;re going to use string literals as object proper=
ties, it makes sense to also use them as named parameters, especially in co=
nstructors with promoted properties. And why stop at constructors? This lea=
ds to the second part of my proposal.<br>Current Situation<br>We can use na=
med parameters in function calls, but only with standard identifiers:<br>``=
`php<br>function myHeaders(...$args) {<br>=C2=A0 =C2=A0 foreach ($args as $=
key =3D&gt; $value) header(&quot;$key: $value&quot;);<br>}<br>```<br><br>To=
 use string literals with special characters, we have to use associative ar=
rays:<br>```php<br>myHeaders(...[&quot;Content-Type&quot; =3D&gt; &quot;app=
lication/json&quot;]);<br>```<br><br>This can be a bit cumbersome and less =
readable, especially for complex data structures.<br>Proposed Enhancement<b=
r>What if we could use string literals as named parameters? It might look s=
omething like this:<br>```php<br>foo(&quot;Content-Type&quot;: &quot;applic=
ation/json&quot;);<br>```<br><br>I think this syntax could offer several ad=
vantages:<br><br>Improved Readability: Our code could become clearer and mo=
re aligned with natural data representation.<br>Automatic Parameter Mapping=
: We could map string literals to corresponding parameters without requirin=
g manual intervention.<br>Simplified Constructor Usage: This could be espec=
ially beneficial for constructors where we need to pass complex data struct=
ures directly.<br><br>Implementation Considerations<br>Of course, implement=
ing these changes would require some work:<br><br>The PHP engine would need=
 to accommodate string literals as valid property names and named parameter=
s, both at runtime and in class/function definitions.<br>We&#39;d need to c=
arefully manage compatibility with existing code to ensure traditional prop=
erty access remains unaffected.<br>We&#39;d need to decide whether to allow=
 string literals as parameters in function/method declarations or only in f=
unction calls (to be retrieved by func_get_args() or variadic functions), w=
ith exceptions for constructors with promoted properties.<br><br>I&#39;m re=
ally interested to hear what you all think about this proposal. Do you see =
potential benefits or challenges that I might have overlooked? How do you t=
hink this could impact your day-to-day coding?<br>Looking forward to a grea=
t discussion!<br>Best regards,<br>Hammed</div>

--0000000000007a9d33062115c7c2--