Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125399 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id D7A3F1A00BD for ; Tue, 3 Sep 2024 00:00:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725321735; bh=jVqZYRZ23Rlc3N2SJWmMPTadUicWSlMHBaNPKJvJjk0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=J68Bo/3vm5+AbfDrhQ9uCabuplICAfSWqx0yTVKCPhhFGh579BmsbVKDP2XYSbHzQ 7NUNavNhOYt19gQSGtoxN19paQYfR9/PVNgtkAFWcEpArY3laHY3ODHtqdh857HrUs crM1txYdTyqVKfmVI24Ayo3m+6BjmJ+mkHTqZCXJzSc1uEM3cblvLrQADKWz9xiOM/ A+/biPhXorXZr3lCI2p83I3PRlxcgKk/lnKFMC7t+e/W3Xav9bZfM/aFgNCMyfoxsX ITLPSlNohvMx9DZ5xYhbYDXU4jG83lTD0+T4CY0goTuBMgVDW5Ef4YQtxSogMk1RmH bfXg4iks9XNcg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8E84A180071 for ; Tue, 3 Sep 2024 00:02:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 3 Sep 2024 00:02:12 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-70f73ca989aso1524334a34.2 for ; Mon, 02 Sep 2024 17:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725321615; x=1725926415; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=S0YGuOGyVoECH3Cn6cZBpVWlG4wJd6AiqKpu7wKlwSk=; b=Uj6NlLsFFrAQyzFEXKJPMjhH7DWw6K6DWNUVD9HfaRmX9pYNQug1Am6InXA0JL9SWE YmtkDAbl2XnCFL4EivsrTmO6tOMOgrM4bBcBhuAW3Le8IfeytUDtO6u+sPGvl4S2CPqy Y4mBvdDzlPW9wmfqMJgu85CtltrxTmzEyW5uS4VAMDbTCEv/cuV4GBDy7SNqAgSSa9Ww vpe86Th71w4cPqwupncah5ZcgSdYRHQcj5vcxR2HLYZ4bdxoEhKfse4fZbgFfSNcmFpN C0KrDDXOSjLdq41/yuhtNqRDSp2kJH4Bbb2zytQxjmfr1ca3AqwiTUHdYfAcQLrUZOhm 8SPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725321615; x=1725926415; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=S0YGuOGyVoECH3Cn6cZBpVWlG4wJd6AiqKpu7wKlwSk=; b=Xh+xVOIQ2kRBcblmWmKZviTbJWLLBpg/nvpTgHY/EqeFADbcbsgU68fb0HRuPuDhzV 11pYcB6ncO0Gvmx7EYbNGZ9LwlKebri2wm6iBRpgj5rrSxWHzToukSucdKB5mzQU7xPe 30bg85g/0dcDoOQxzD0Db26NBoROy2iWdEg10ND7LonSuW063Wrm80a06lx2K6blcslp SmNwA7pO/w4wt4KGL/DWU7Q/JlUOSF6CQjwAjfHj627n5yme8I2X4t1iPcOUFGBiNiUL fKATaoCU5keogKzow0XZY64FbYTU/qnfTcOWPcTaZ9NFth6lFLR6RyhDwl4JFv4WRUN0 i1VA== X-Gm-Message-State: AOJu0YzuYdwhsvN/YA2xnEUxBaeT/l/HVX40N8uVzFGm4kOw4sFTayXQ Z3Fdjbnai8WFWct1CNDuTE/EQHLz/Zn4e1Z2U1FWMD0ZbtIJ6cwciJYO84NsNMhhJpBQK7JqkFo Ir0o2h4aSD07yb7vznnVZwWZ70fLEjvlZ X-Google-Smtp-Source: AGHT+IFiO1V7R0ZYQQiOr7FfmiYK6Y9oV65AVeoUhjDG0zPu+prgHuzSvRMT24VYGOKHCQEObxUaU5GJWYvgJYMLHLY= X-Received: by 2002:a05:6830:b8a:b0:703:5cde:3a1f with SMTP id 46e09a7af769-70f5c35434fmr17937320a34.1.1725321614687; Mon, 02 Sep 2024 17:00:14 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <0418049b-7981-40a0-a0f9-2430eceb7d12@app.fastmail.com> In-Reply-To: <0418049b-7981-40a0-a0f9-2430eceb7d12@app.fastmail.com> Date: Mon, 2 Sep 2024 18:00:03 -0600 Message-ID: Subject: Re: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as Object Properties and Named Parameters in PHP To: Rob Landers Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000f7869b06212bbdc4" From: hamiegold@gmail.com (Hammed Ajao) --000000000000f7869b06212bbdc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 2, 2024 at 1:50=E2=80=AFPM Rob Landers wrot= e: > 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 when > working with string literals. I'm looking forward to hearing your thought= s > 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 character= s > 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"; > } > > $obj =3D new Foo(); > $obj->contentType =3D "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 =3D [ > "Content-Type" =3D> "application/json", > "X-Custom-Header" =3D> "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 wha= t > I'm thinking: > ```php > class MyHeaders { > > public function __construct( > public string "Content-Type" =3D "application/json", > public string "Cache-Control" =3D "no-cache, no-store, > must-revalidate", > 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", > ) {} > > 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 =3D> $value) { > header("$name: $value"); > } > } > } > > $headers =3D new MyHeaders("Content-Type": "application/json", > "X-Custom-Header": "value"); > // or > $headers =3D MyHeaders::create("Content-Type": "text/html; charset=3Dutf-= 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 thi= s > 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 ca= n > 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 sens= e > to also use them as named parameters, especially in constructors with > promoted properties. And why stop at constructors? This leads to the seco= nd > 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"); > } > ``` > > To use string literals with special characters, we have to use associativ= e > arrays: > ```php > myHeaders(...["Content-Type" =3D> "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 correspondin= g > 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 propert= y > 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 b= y > 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? Ho= w > 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 > syntax): > > 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 file > 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 > direct answer to what you are seeking, but it gets pretty close. > > =E2=80=94 Rob > Hi Rob, That's actually pretty neat, but it starts to fall apart when you need the unicode representation e.g. converting to json :https://3v4l.org/VXfDl . Hammed --000000000000f7869b06212bbdc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 2, 2024 at 1:50=E2=80=AFP= M Rob Landers <rob@bottled.codes> wrote:
=
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&= #39;s flexibility and consistency, especially when working with string lite= rals. 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 e= asier:

Support for String Literals as Object P= roperties
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 acces= s data, particularly in scenarios like working with HTTP headers where we o= ften 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 st= andard identifiers:
```php
class Foo {
=C2=A0 =C2=A0 public string $contentType =3D "application/json&q= uot;;
}

$obj =3D new Foo();
<= /div>
$obj->contentType =3D "text/html";
```=

But when we're dealing with data that inc= ludes non-standard characters or strings (think HTTP headers), we often end= up using associative arrays:
```php
$headers = =3D [
=C2=A0 =C2=A0 "Content-Type" =3D> "ap= plication/json",
=C2=A0 =C2=A0 "X-Custom-Header&quo= t; =3D> "value"
];
```

I think we can all agree that this reliance on arrays can= make our code less intuitive, especially when we're managing complex d= ata structures.
Proposed Enhancement
What if we= could use string literals as object property names? Here's what I'= m thinking:
```php
class MyHeaders {
<= div>
=C2=A0 =C2=A0 public function __construct(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string "Content-Type" =3D &qu= ot;application/json",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public= string "Cache-Control" =3D "no-cache, no-store, must-revali= date",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string "P= ragma" =3D "no-cache",
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 public string "Expires" =3D "0",
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 public string "X-Frame-Options" =3D &= quot;SAMEORIGIN",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public str= ing "X-XSS-Protection" =3D "1; mode=3Dblock",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string "X-Content-Type-Options= " =3D "nosniff",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 p= ublic string "Referrer-Policy" =3D "strict-origin-when-cross= -origin",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public string &quo= t;Access-Control-Allow-Origin" =3D "*",
=C2=A0= =C2=A0 =C2=A0 =C2=A0 public string "X-Custom-Header" =3D "v= alue",
=C2=A0 =C2=A0 ) {}

= =C2=A0 =C2=A0 public static function create(string ...$headers): self {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return new self(...$headers); // Thr= ows an error if an unknown named parameter is passed
=C2=A0 = =C2=A0 }

=C2=A0 =C2=A0 public function dispatc= h(): void {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 foreach ((array) $thi= s as $name =3D> $value) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 header("$name: $value");
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
}

$headers =3D new MyHeaders("Content-Type": "= application/json", "X-Custom-Header": "value");
// or
$headers =3D MyHeaders::create("Conten= t-Type": "text/html; charset=3Dutf-8", "X-Custom-Header= ": "value");
$headers->dispatch();
```
This would allow us to include characters in proper= ty 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 represe= ntations of data within objects.
Enhanced Consistency: This a= ligns with the proposed support for string literals as named parameters, cr= eating a more uniform language experience.
Simplification: It= could reduce our need for associative arrays, which can be more error-pron= e and less intuitive.

2. String Literals as Na= med Parameters in Function Calls
If we're going to use st= ring literals as object properties, it makes sense to also use them as name= d 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 funct= ion calls, but only with standard identifiers:
```php
function myHeaders(...$args) {
=C2=A0 =C2=A0 foreach (= $args as $key =3D> $value) header("$key: $value");
}
```

To use string literals = with special characters, we have to use associative arrays:
`= ``php
myHeaders(...["Content-Type" =3D> "ap= plication/json"]);
```

This= can be a bit cumbersome and less readable, especially for complex data str= uctures.
Proposed Enhancement
What if we could = use string literals as named parameters? It might look something like this:=
```php
foo("Content-Type": "app= lication/json");
```

I thin= k this syntax could offer several advantages:

= Improved Readability: Our code could become clearer and more aligned with n= atural data representation.
Automatic Parameter Mapping: We c= ould map string literals to corresponding parameters without requiring manu= al intervention.
Simplified Constructor Usage: This could be = especially beneficial for constructors where we need to pass complex data s= tructures directly.

Implementation Considerati= ons
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 runt= ime and in class/function definitions.
We'd need to caref= ully manage compatibility with existing code to ensure traditional property= access remains unaffected.
We'd need to decide whether t= o allow string literals as parameters in function/method declarations or on= ly in function calls (to be retrieved by func_get_args() or variadic functi= ons), with exceptions for constructors with promoted properties.
<= div>
I'm really interested to hear what you all think abo= ut 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 re= gards,
Hammed

Hey Hammed,

This gets into the parser and its= definition of "LABEL" (below PHP's syntax):
LABEL [a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*
<= br>
This means the first letter must be alpha-numeric ascii, or h= igher. And you can actually just use the latter part and whatever encoding = your file is (usually utf8):

For example, this= is valid PHP:

class HTML {
=C2= =A0=C2=A0=C2=A0 public string $Content=E2=80=93Type;
=C2=A0= =C2=A0=C2=A0 public string $=E1=8B=90xl;
=C2=A0=C2=A0=C2=A0 p= ublic string $=F0=9D=9F=B70sm;
}

https://3v4l.org/KgJK= m

You can also use emojis or look-alikes a= s much as you want. It's not a direct answer to what you are seeking, b= ut it gets pretty close.

=E2=80=94 Rob
H= i Rob,

That's actually pretty neat, but it sta= rts to fall apart when you need the unicode representation e.g. converting = to json :https://3v4l.org/VXfDl .

Hammed
--000000000000f7869b06212bbdc4--