Re: Pre-RFC Discussion: Support for String Literals as Object Properties and Named Parameters in PHP

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 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 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–Type; public string $ዐxl; public string $𝟷0sm; } 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. — Rob