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
