Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125392 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 9A23D1A00BD for ; Mon, 2 Sep 2024 17:49:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725299466; bh=+5GWHoPxy/vTKBNe87tZIqDBkw/Eh16djr2uzBDbC6c=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lvy/75XFqRd1TxfvzSooYWnAKECbEXzY0x7FH+pVKZKUEPdWY84iZKdJ1UHXiF+O3 VqJViHrVqOQzctR8umKmCdDFEbDuQqUNSBN0oD9ouqmu4FL9hFCDECTSCGhAgjvUpt tlvKFsWvrKMn9sxPH4X89/0mAWeLEpNu8MSx5FPkgFZ8b/zbr+A47KIKMjSBVkDgD4 5ndts99DMkpCs7S3Xts4eR6UC8nRuSOCOHMpeQHCoPUOkmjLuAnL0/Z4/xZOAbk1XJ ruZ9SOi70aBekZTC8gPbpMJ+Q6iIqO9u9BwyYCiV29NkEIEpzTa5iWFXn+TCYuIcVF LqHGJ8OLku4NA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E1736180079 for ; Mon, 2 Sep 2024 17:51:04 +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 ; Mon, 2 Sep 2024 17:51:04 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-70f6cb5518aso1956333a34.1 for ; Mon, 02 Sep 2024 10:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725299347; x=1725904147; 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=8BWGLol843svNplGz5jCq4kDwas0dZcY1EvTwmVGF90=; b=Gl8qzeuurzaKCFQR7XMCILN1eGMNUOS6cNVUgAOkhE/1GzTfUgiAlGiBx4F881Z2Sx VE5xN6ngISWydot09qelATPeH520K4Nbv4FaCV0lQrPj4dYktyJhDosK6kvbPl/xbAbl XfpJ2k+iWmjMzl71ZNaLYLvmHTBRPbZaV3MLurB5bFittyCNA+Y8h0UX6xHBJJYqRLX+ VJASqFtZp03c/VMJUbwKxsexXc9k42+LM0cWya0JRoON3NsNtcnrEVDVseMICBF1uLFn hT+MZ3Qj7itABl3UGwBjkAfAel/2re2iEAApnA+6YLx9WDTSD0KrB8hFj9PpJ3a8FWoa b/qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725299347; x=1725904147; 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=8BWGLol843svNplGz5jCq4kDwas0dZcY1EvTwmVGF90=; b=tIO/JZriPY5JamTPBkHEFselQgp3xRiflxcy/j90YwXRbzHgRXm+osptfs64wVsVAt klszc5ZCWJbfr79Cz9Vf2rPcV9rXVh9zKtpfwffqJwGT8ru+TSU7WGyiZeJx3/WkW5uk ge6Sx6B5YVeQgVMJH93qSF+Svxkv6Coc5OhpG9aZ2LB46JXuzDHx172yl9S0y2JjI8vO ZLm/6eoFpBLqR/V4GpY8B39HAtarC3Iao0vFFx0WVXUUq/yRvUbNT8CNgwbSVuxQBxYI dyy6mwy2RxOq5J2thpija5Z+ipeexZWqGopDKAO9Q1/ZkSKYKuhrMi5z6bhT7iLgz2he fdhw== X-Gm-Message-State: AOJu0YwGlW1r5cHCayYKmi/b8KYneeEIIcUNJyj4w8KTQJxJIvL+9i85 pe44yw0Qm6raSgnDo6kjGMJcNyFMCHXSOKD4VfiAIP9qmUfAe6bbYAa6GAEZUFpVZ3mEMAWrqhZ ZbyLemug/LO8zt2+W/yujLYoUhOI= X-Google-Smtp-Source: AGHT+IGxNhQzY+TMoSJPmoo3ua1svcg/UyTJDIJZHQHUTqoDkVbF1CyXGIFFtuqIXK6FxLPx/bftzcZMGb45UZ+TeJ0= X-Received: by 2002:a05:6830:264a:b0:709:425f:e6d3 with SMTP id 46e09a7af769-70f71ee9ce8mr11294153a34.7.1725299346906; Mon, 02 Sep 2024 10:49:06 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <1C1BB102-EE71-49A6-A057-C727A39FC38F@newclarity.net> In-Reply-To: <1C1BB102-EE71-49A6-A057-C727A39FC38F@newclarity.net> Date: Mon, 2 Sep 2024 11:48:55 -0600 Message-ID: Subject: Re: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as Object Properties and Named Parameters in PHP To: Mike Schinkel Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000b426a40621268eb6" From: hamiegold@gmail.com (Hammed Ajao) --000000000000b426a40621268eb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mike, Thanks for reading and responding. While your enum does technically address some of the issues I am discussing, it does so in a very verbose and cumbersome way. - First you need the DefaultValue attribute - Then you need to use it on each of your `properties` - You also need to define an identifier for the const which defeats the purpose of using literal strings - Then you need to use reflection to access the properties - Then you're left with : MyHeaders::create(MyHeaders::CONTENT_TYPE, "plain/text", MyHeaders::X_CUSTOM_HEADER,"new_value"); which isn't super clear that it's mapping every other value to the one before it. As for the idea that an object property must be a valid identifier, I'm not sure that's correct. Objects can have integer properties natively i.e $obj->{1}, and literal string properties are already possible when you cast an array to an object Let me show you a few other use cases i've run into ```php class Sizes { public function __construct( private string $sm, private string $md, private string $lg, private string $xl, private string $2xl, // will throw private string "10xl", // wouldn't this be nice ) {} } function htmlElement(string $tag, string $content, string|bool ...$attr) {} htmlElement("div", "Hello, world!", class: "greeting", id: "greeting", "data-foo": "bar"); ``` Cheers, Hammed. On Mon, Sep 2, 2024 at 8:51=E2=80=AFAM Mike Schinkel = wrote: > > On Sep 1, 2024, at 5:47 PM, 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 live= s > 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 > what 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=3Dut= f-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 > 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 wi= th > 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 > associative 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 > 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/functio= n > definitions. > > We'd need to carefully manage compatibility with existing code to ensur= e > 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. D= o > 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! > > I know if it not exactly what you asked for, but have you considered usin= g > Enums and Attributes instead? > > Here is a working single file example of what I am suggesting: > > https://gist.github.com/mikeschinkel/b71beb8b7ee626ba9e6ea4afaba11e22 > > I know it is more boilerplate, but does it address the same issues you > were trying to address, or not? If not, in what ways does not not addres= s > your use-cases? > > I know it uses arrays which you seem to want to avoid, but it only uses > they are the result of operations on an enum which are not arrays that yo= u > need to maintain in your code. > > Are there other use-cases besides working with HTTP header where Enums an= d > Attributes would not address the issues you were trying to address? > > Generally I am one who welcomes new feature ideas, but I fear that string > literals as object properties would break a valuable assumption that all > properties must be a valid identifier. Without that assumption I fear man= y > things that would become more complex. > > Also there are chances such a change could break a lot of userland code > that makes that same assumption. I know from using MySQL where field name= s > do not need to be valid identifiers that such a "feature" complicates > coding, makes certain bugs easier to create, and often makes code less > elegant (read "uglier") that it would otherwise be. > > So I am sympathetic to the desire to improve the language. However I fear > this specific change would create more pain than pleasure. Better IMO to > look for less disruptive solutions to achieve the same goals. For example= , > if the Enum+Attributes approach meets your needs aside from having too mu= ch > boilerplate, maybe we could enhance PHP to have less of that boilerplate? > > -Mike > P.S. I want to (again) thank those who brought us Enums as I think they > are one of the best new features PHP has added in the past decade. #fwiw > > --000000000000b426a40621268eb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Mike,

Thanks=C2=A0for readin= g and responding. While your enum does technically address some of the issu= es I am discussing, it does so in a very verbose and cumbersome way.
<= div>- First you need the DefaultValue attribute
- Then you need t= o use it on each of your `properties`
- You also need to define a= n identifier for the const which defeats the purpose of using literal strin= gs
- Then you need to use reflection to access the properties
- Then you're left with : MyHeaders::create(MyHeaders::CONTENT_T= YPE, "plain/text", MyHeaders::X_CUSTOM_HEADER,"new_value&quo= t;); which isn't super clear that it's mapping every other value to= the one before it.

As for the idea that an object= property must be a valid identifier, I'm not sure that's correct. = Objects can have integer properties natively i.e $obj->{1}, and literal = string properties are already possible when you=C2=A0cast an array to an ob= ject

Let me show you a few other use cases i'v= e run into

```php

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 class Sizes {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 public function __construct(
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 private string $sm,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 priv= ate string $md,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 private string $lg,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 private string $xl,
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 private string $2xl, // w= ill throw
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 private string "10xl", // wouldn't this be nice
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ) {}
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 function htmlElement(string $tag, string $content, string|bool ...$= attr) {}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 htmlElement("div= ", "Hello, world!", class: "greeting", id: "g= reeting", "data-foo": "bar");

```
Cheers,
Hammed.

On Mon, Sep 2, 2024 = at 8:51=E2=80=AFAM Mike Schinkel <mike@newclarity.net> wrote:
> On Sep 1, 2024, at 5:47 PM, Hamm= ed Ajao <hamieg= old@gmail.com> 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, especia= lly when working with string literals. I'm looking forward to hearing y= our 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 mor= e 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 {
>=C2=A0 =C2=A0 =C2=A0public string $contentType =3D "application/js= on";
> }
>
> $obj =3D new Foo();
> $obj->contentType =3D "text/html";
> ```
>
> But when we're dealing with data that includes non-standard charac= ters or strings (think HTTP headers), we often end up using associative arr= ays:
> ```php
> $headers =3D [
>=C2=A0 =C2=A0 =C2=A0"Content-Type" =3D> "application/= json",
>=C2=A0 =C2=A0 =C2=A0"X-Custom-Header" =3D> "value&quo= t;
> ];
> ```
>
> 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 structure= s.
> Proposed Enhancement
> What if we could use string literals as object property names? Here= 9;s what I'm thinking:
> ```php
> class MyHeaders {
>
>=C2=A0 =C2=A0 =C2=A0public function __construct(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "Content-Type"= ; =3D "application/json",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "Cache-Control&quo= t; =3D "no-cache, no-store, must-revalidate",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "Pragma" =3D = "no-cache",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "Expires" =3D= "0",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "X-Frame-Options&q= uot; =3D "SAMEORIGIN",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "X-XSS-Protection&= quot; =3D "1; mode=3Dblock",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "X-Content-Type-Op= tions" =3D "nosniff",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "Referrer-Policy&q= uot; =3D "strict-origin-when-cross-origin",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "Access-Control-Al= low-Origin" =3D "*",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string "X-Custom-Header&q= uot; =3D "value",
>=C2=A0 =C2=A0 =C2=A0) {}
>
>=C2=A0 =C2=A0 =C2=A0public static function create(string ...$headers): = self {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return new self(...$headers); // Thro= ws an error if an unknown named parameter is passed
>=C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0public function dispatch(): void {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foreach ((array) $this as $name =3D&g= t; $value) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0header("$name: $va= lue");
>=C2=A0 =C2=A0 =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("Content-Type": "text/ht= ml; charset=3Dutf-8", "X-Custom-Header": "value");=
> $headers->dispatch();
> ```
> This would allow us to include characters in property names that aren&= #39;t typically allowed in PHP identifiers, like hyphens or spaces. I think= this could make our code more readable and aligned with natural data repre= sentation.
> Benefits
>
> 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 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 mak= es sense to also use them as named parameters, especially in constructors w= ith promoted properties. And why stop at constructors? This leads to the se= cond part of my proposal.
> Current Situation
> We can use named parameters in function calls, but only with standard = identifiers:
> ```php
> function myHeaders(...$args) {
>=C2=A0 =C2=A0 =C2=A0foreach ($args as $key =3D> $value) header("= ;$key: $value");
> }
> ```
>
> To use string literals with special characters, we have to use associa= tive arrays:
> ```php
> myHeaders(...["Content-Type" =3D> "application/json&= quot;]);
> ```
>
> 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");
> ```
>
> I think this syntax could offer several advantages:
>
> 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.
>
> Implementation Considerations
> Of course, implementing these changes would require some work:
>
> The PHP engine would need to accommodate string literals as valid prop= erty names and named parameters, both at runtime and in class/function defi= nitions.
> 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 constructor= s with promoted properties.
>
> I'm really interested to hear what you all think about this propos= al. Do you see potential benefits or challenges that I might have overlooke= d? How do you think this could impact your day-to-day coding?
> Looking forward to a great discussion!

I know if it not exactly what you asked for, but have you considered using = Enums and Attributes instead?

Here is a working single file example of what I am suggesting:

https://gist.github.com/mikesch= inkel/b71beb8b7ee626ba9e6ea4afaba11e22

I know it is more boilerplate, but does it address the same issues you were= trying to address, or not?=C2=A0 If not, in what ways does not not address= your use-cases?

I know it uses arrays which you seem to want to avoid, but it only uses the= y are the result of operations on an enum which are not arrays that you nee= d to maintain in your code.

Are there other use-cases besides working with HTTP header where Enums and = Attributes would not address the issues you were trying to address?=C2=A0 <= br>
Generally I am one who welcomes new feature ideas, but I fear that string l= iterals as object properties would break a valuable assumption that all pro= perties must be a valid identifier. Without that assumption I fear many thi= ngs that would become more complex.

Also there are chances such a change could break a lot of userland code tha= t makes that same assumption. I know from using MySQL where field names do = not need to be valid identifiers that such a "feature" complicate= s coding, makes certain bugs easier to create, and often makes code less el= egant (read "uglier") that it would otherwise be.

So I am sympathetic to the desire to improve the language. However I fear t= his specific change would create more pain than pleasure. Better IMO to loo= k for less disruptive solutions to achieve the same goals. For example, if = the Enum+Attributes approach meets your needs aside from having too much bo= ilerplate, maybe we could enhance PHP to have less of that boilerplate?

-Mike
P.S. I want to (again) thank those who brought us Enums as I think they are= one of the best new features PHP has added in the past decade. #fwiw

--000000000000b426a40621268eb6--