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
