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.
- String Literals as Object Properties
Current Situation
As we all know, we typically define and access object properties using standard identifiers:
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:
$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:
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.
- 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:
function myHeaders(...$args) {
foreach ($args as $key => $value) header("$key: $value");
}
To use string literals with special characters, we have to use associative arrays:
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:
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
