Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125394
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 02 Sep 2024 21:49:22 +0200
To: internals@lists.php.net
Message-ID: <0418049b-7981-40a0-a0f9-2430eceb7d12@app.fastmail.com>
In-Reply-To: 
 <CA+Jpajmb6vp+yLG8Z78TafrCu3ZyYFrw5PL5JFSsAeA_ZX_Jjw@mail.gmail.com>
References: 
 <CA+Jpajmb6vp+yLG8Z78TafrCu3ZyYFrw5PL5JFSsAeA_ZX_Jjw@mail.gmail.com>
Subject: Re: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as Object
 Properties and Named Parameters in PHP
Content-Type: multipart/alternative;
 boundary=ddba43b12dc441fe91ef6e8dc737f87a
From: rob@bottled.codes ("Rob Landers")

--ddba43b12dc441fe91ef6e8dc737f87a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 1, 2024, at 23:47, Hammed Ajao wrote:
> 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 w=
hen working with string literals. I'm looking forward to hearing your th=
oughts and feedback on this proposal.
> Introduction
> I'm suggesting two enhancements to PHP that I think could make our liv=
es as developers a bit easier:
>=20
> Support for String Literals as Object Properties
> Support for String Literals as Named Parameters in Function Calls
>=20
> The main goal here is to reduce our reliance on arrays and provide mor=
e intuitive ways to define and access data, particularly in scenarios li=
ke working with HTTP headers where we often deal with non-standard chara=
cters 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 =3D "application/json";
> }
>=20
> $obj =3D new Foo();
> $obj->contentType =3D "text/html";
> ```
>=20
> But when we're dealing with data that includes non-standard characters=
 or strings (think HTTP headers), we often end up using associative arra=
ys:
> ```php
> $headers =3D [
>     "Content-Type" =3D> "application/json",
>     "X-Custom-Header" =3D> "value"
> ];
> ```
>=20
> I think we can all agree that this reliance on arrays can make our cod=
e 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 {
>=20
>     public function __construct(
>         public string "Content-Type" =3D "application/json",
>         public string "Cache-Control" =3D "no-cache, no-store, must-re=
validate",
>         public string "Pragma" =3D "no-cache",
>         public string "Expires" =3D "0",
>         public string "X-Frame-Options" =3D "SAMEORIGIN",
>         public string "X-XSS-Protection" =3D "1; mode=3Dblock",
>         public string "X-Content-Type-Options" =3D "nosniff",
>         public string "Referrer-Policy" =3D "strict-origin-when-cross-=
origin",
>         public string "Access-Control-Allow-Origin" =3D "*",
>         public string "X-Custom-Header" =3D "value",
>     ) {}
>=20
>     public static function create(string ...$headers): self {
>         return new self(...$headers); // Throws an error if an unknown=
 named parameter is passed
>     }
>=20
>     public function dispatch(): void {
>         foreach ((array) $this as $name =3D> $value) {
>             header("$name: $value");
>         }
>     }
> }
>=20
> $headers =3D new MyHeaders("Content-Type": "application/json", "X-Cust=
om-Header": "value");
> // or
> $headers =3D MyHeaders::create("Content-Type": "text/html; charset=3Du=
tf-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 rep=
resentation.
> Benefits
>=20
> Greater Flexibility: We could create more natural and direct represent=
ations of data within objects.
> Enhanced Consistency: This aligns with the proposed support for string=
 literals as named parameters, creating a more uniform language experien=
ce.
> Simplification: It could reduce our need for associative arrays, which=
 can be more error-prone and less intuitive.
>=20
> 2. String Literals as Named Parameters in Function Calls
> If we're going to use string literals as object properties, it makes s=
ense to also use them as named parameters, especially in constructors wi=
th 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 =3D> $value) header("$key: $value");
> }
> ```
>=20
> To use string literals with special characters, we have to use associa=
tive arrays:
> ```php
> myHeaders(...["Content-Type" =3D> "application/json"]);
> ```
>=20
> 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 loo=
k something like this:
> ```php
> foo("Content-Type": "application/json");
> ```
>=20
> I think this syntax could offer several advantages:
>=20
> Improved Readability: Our code could become clearer and more aligned w=
ith natural data representation.
> Automatic Parameter Mapping: We could map string literals to correspon=
ding parameters without requiring manual intervention.
> Simplified Constructor Usage: This could be especially beneficial for =
constructors where we need to pass complex data structures directly.
>=20
> Implementation Considerations
> Of course, implementing these changes would require some work:
>=20
> The PHP engine would need to accommodate string literals as valid prop=
erty names and named parameters, both at runtime and in class/function d=
efinitions.
> We'd need to carefully manage compatibility with existing code to ensu=
re 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 construct=
ors with promoted properties.
>=20
> 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

Hey Hammed,

This gets into the parser and its definition of "LABEL" (below PHP's syn=
tax):

LABEL [a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*

This means the first letter must be alpha-numeric ascii, or higher. And =
you can actually just use the latter part and whatever encoding your fil=
e is (usually utf8):

For example, this is valid PHP:

class HTML {
    public string $Content=E2=80=93Type;
    public string $=E1=8B=90xl;
    public string $=F0=9D=9F=B70sm;
}

https://3v4l.org/KgJKm

You can also use emojis or look-alikes as much as you want. It's not a d=
irect answer to what you are seeking, but it gets pretty close.

=E2=80=94 Rob
--ddba43b12dc441fe91ef6e8dc737f87a
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sun, Sep 1, =
2024, at 23:47, Hammed Ajao wrote:<br></div><blockquote type=3D"cite" id=
=3D"qt" style=3D""><div dir=3D"ltr"><div>Dear PHP internals community,<b=
r></div><div>I hope this email finds you all well. I'd like to propose a=
n idea that I believe could enhance PHP's flexibility and consistency, e=
specially when working with string literals. I'm looking forward to hear=
ing your thoughts and feedback on this proposal.<br></div><div>Introduct=
ion<br></div><div>I'm suggesting two enhancements to PHP that I think co=
uld make our lives as developers a bit easier:<br></div><div><br></div><=
div>Support for String Literals as Object Properties<br></div><div>Suppo=
rt for String Literals as Named Parameters in Function Calls<br></div><d=
iv><br></div><div>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 no=
n-standard characters and strings.<br></div><div>1. String Literals as O=
bject Properties<br></div><div>Current Situation<br></div><div>As we all=
 know, we typically define and access object properties using standard i=
dentifiers:<br></div><div>```php<br></div><div>class Foo {<br></div><div=
>&nbsp; &nbsp; public string $contentType =3D "application/json";<br></d=
iv><div>}<br></div><div><br></div><div>$obj =3D new Foo();<br></div><div=
>$obj-&gt;contentType =3D "text/html";<br></div><div>```<br></div><div><=
br></div><div>But when we're dealing with data that includes non-standar=
d characters or strings (think HTTP headers), we often end up using asso=
ciative arrays:<br></div><div>```php<br></div><div>$headers =3D [<br></d=
iv><div>&nbsp; &nbsp; "Content-Type" =3D&gt; "application/json",<br></di=
v><div>&nbsp; &nbsp; "X-Custom-Header" =3D&gt; "value"<br></div><div>];<=
br></div><div>```<br></div><div><br></div><div>I think we can all agree =
that this reliance on arrays can make our code less intuitive, especiall=
y when we're managing complex data structures.<br></div><div>Proposed En=
hancement<br></div><div>What if we could use string literals as object p=
roperty names? Here's what I'm thinking:<br></div><div>```php<br></div><=
div>class MyHeaders {<br></div><div><br></div><div>&nbsp; &nbsp; public =
function __construct(<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; public s=
tring "Content-Type" =3D "application/json",<br></div><div>&nbsp; &nbsp;=
 &nbsp; &nbsp; public string "Cache-Control" =3D "no-cache, no-store, mu=
st-revalidate",<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; public string =
"Pragma" =3D "no-cache",<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; publi=
c string "Expires" =3D "0",<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; pu=
blic string "X-Frame-Options" =3D "SAMEORIGIN",<br></div><div>&nbsp; &nb=
sp; &nbsp; &nbsp; public string "X-XSS-Protection" =3D "1; mode=3Dblock"=
,<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; public string "X-Content-Typ=
e-Options" =3D "nosniff",<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; publ=
ic string "Referrer-Policy" =3D "strict-origin-when-cross-origin",<br></=
div><div>&nbsp; &nbsp; &nbsp; &nbsp; public string "Access-Control-Allow=
-Origin" =3D "*",<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; public strin=
g "X-Custom-Header" =3D "value",<br></div><div>&nbsp; &nbsp; ) {}<br></d=
iv><div><br></div><div>&nbsp; &nbsp; public static function create(strin=
g ...$headers): self {<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; return =
new self(...$headers); // Throws an error if an unknown named parameter =
is passed<br></div><div>&nbsp; &nbsp; }<br></div><div><br></div><div>&nb=
sp; &nbsp; public function dispatch(): void {<br></div><div>&nbsp; &nbsp=
; &nbsp; &nbsp; foreach ((array) $this as $name =3D&gt; $value) {<br></d=
iv><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; header("$name: $value"=
);<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; }<br></div><div>&nbsp; &nbs=
p; }<br></div><div>}<br></div><div><br></div><div>$headers =3D new MyHea=
ders("Content-Type": "application/json", "X-Custom-Header": "value");<br=
></div><div>// or<br></div><div>$headers =3D MyHeaders::create("Content-=
Type": "text/html; charset=3Dutf-8", "X-Custom-Header": "value");<br></d=
iv><div>$headers-&gt;dispatch();<br></div><div>```<br></div><div>This wo=
uld allow us to include characters in property names that aren't typical=
ly allowed in PHP identifiers, like hyphens or spaces. I think this coul=
d make our code more readable and aligned with natural data representati=
on.<br></div><div>Benefits<br></div><div><br></div><div>Greater Flexibil=
ity: We could create more natural and direct representations of data wit=
hin objects.<br></div><div>Enhanced Consistency: This aligns with the pr=
oposed support for string literals as named parameters, creating a more =
uniform language experience.<br></div><div>Simplification: It could redu=
ce our need for associative arrays, which can be more error-prone and le=
ss intuitive.<br></div><div><br></div><div>2. String Literals as Named P=
arameters in Function Calls<br></div><div>If we're going to use string l=
iterals as object properties, it makes sense to also use them as named p=
arameters, especially in constructors with promoted properties. And why =
stop at constructors? This leads to the second part of my proposal.<br><=
/div><div>Current Situation<br></div><div>We can use named parameters in=
 function calls, but only with standard identifiers:<br></div><div>```ph=
p<br></div><div>function myHeaders(...$args) {<br></div><div>&nbsp; &nbs=
p; foreach ($args as $key =3D&gt; $value) header("$key: $value");<br></d=
iv><div>}<br></div><div>```<br></div><div><br></div><div>To use string l=
iterals with special characters, we have to use associative arrays:<br><=
/div><div>```php<br></div><div>myHeaders(...["Content-Type" =3D&gt; "app=
lication/json"]);<br></div><div>```<br></div><div><br></div><div>This ca=
n be a bit cumbersome and less readable, especially for complex data str=
uctures.<br></div><div>Proposed Enhancement<br></div><div>What if we cou=
ld use string literals as named parameters? It might look something like=
 this:<br></div><div>```php<br></div><div>foo("Content-Type": "applicati=
on/json");<br></div><div>```<br></div><div><br></div><div>I think this s=
yntax could offer several advantages:<br></div><div><br></div><div>Impro=
ved Readability: Our code could become clearer and more aligned with nat=
ural data representation.<br></div><div>Automatic Parameter Mapping: We =
could map string literals to corresponding parameters without requiring =
manual intervention.<br></div><div>Simplified Constructor Usage: This co=
uld be especially beneficial for constructors where we need to pass comp=
lex data structures directly.<br></div><div><br></div><div>Implementatio=
n Considerations<br></div><div>Of course, implementing these changes wou=
ld require some work:<br></div><div><br></div><div>The PHP engine would =
need to accommodate string literals as valid property names and named pa=
rameters, both at runtime and in class/function definitions.<br></div><d=
iv>We'd need to carefully manage compatibility with existing code to ens=
ure traditional property access remains unaffected.<br></div><div>We'd n=
eed 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.<br></div><div><br></div><div>I'm really interested=
 to hear what you all think about this proposal. Do you see potential be=
nefits or challenges that I might have overlooked? How do you think this=
 could impact your day-to-day coding?<br></div><div>Looking forward to a=
 great discussion!<br></div><div>Best regards,<br></div><div>Hammed<br><=
/div></div></blockquote><div><br></div><div>Hey Hammed,<br></div><div><b=
r></div><div>This gets into the parser and its definition of "LABEL" (be=
low PHP's syntax):<br></div><div><br></div><div>LABEL	[a-zA-Z_\x80-\xff]=
[a-zA-Z0-9_\x80-\xff]*<br></div><div><br></div><div>This means the first=
 letter must be alpha-numeric ascii, or higher. And you can actually jus=
t use the latter part and whatever encoding your file is (usually utf8):=
<br></div><div><br></div><div>For example, this is valid PHP:<br></div><=
div><br></div><div>class HTML {<br></div><div>&nbsp;&nbsp;&nbsp; public =
string $Content=E2=80=93Type;<br></div><div>&nbsp;&nbsp;&nbsp; public st=
ring $=E1=8B=90xl;<br></div><div>&nbsp;&nbsp;&nbsp; public string $=F0=9D=
=9F=B70sm;<br></div><div>}<br></div><div><br></div><div><a href=3D"https=
://3v4l.org/KgJKm">https://3v4l.org/KgJKm</a><br></div><div><br></div><d=
iv>You can also use emojis or look-alikes as much as you want. It's not =
a direct answer to what you are seeking, but it gets pretty close.<br></=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></bod=
y></html>
--ddba43b12dc441fe91ef6e8dc737f87a--