Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125389
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as
 Object Properties and Named Parameters in PHP
In-Reply-To: <CA+Jpajmb6vp+yLG8Z78TafrCu3ZyYFrw5PL5JFSsAeA_ZX_Jjw@mail.gmail.com>
Date: Mon, 2 Sep 2024 10:51:16 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <1C1BB102-EE71-49A6-A057-C727A39FC38F@newclarity.net>
References: <CA+Jpajmb6vp+yLG8Z78TafrCu3ZyYFrw5PL5JFSsAeA_ZX_Jjw@mail.gmail.com>
To: Hammed Ajao <hamiegold@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Sep 1, 2024, at 5:47 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
>=20
> 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:
>=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 =
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 =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 =
arrays:
> ```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 =
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 {
>=20
>     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",
>     ) {}
>=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-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 this could make our code more readable and aligned with natural =
data representation.
> Benefits
>=20
> 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.
>=20
> 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 =3D> $value) header("$key: $value");
> }
> ```
>=20
> To use string literals with special characters, we have to use =
associative 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 =
look 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 =
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.
>=20
> Implementation Considerations
> Of course, implementing these changes would require some work:
>=20
> 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.
>=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!

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/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 =
address 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 =
you need 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? =20=


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 many 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 =
names 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 much 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