Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125395
Content-Type: text/plain;
	charset=utf-8
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+JpajmLvYGGTRu36xGtuwC_KtZf8q=Rw-vTe6Ze7OZyVO0EpQ@mail.gmail.com>
Date: Mon, 2 Sep 2024 15:52:51 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <3DFFDF2E-5C2F-4DEA-9C47-3830B09D9406@newclarity.net>
References: <CA+Jpajmb6vp+yLG8Z78TafrCu3ZyYFrw5PL5JFSsAeA_ZX_Jjw@mail.gmail.com>
 <1C1BB102-EE71-49A6-A057-C727A39FC38F@newclarity.net>
 <CA+JpajmLvYGGTRu36xGtuwC_KtZf8q=Rw-vTe6Ze7OZyVO0EpQ@mail.gmail.com>
To: Hammed Ajao <hamiegold@gmail.com>
From: mike@newclarity.net (Mike Schinkel)



> On Sep 2, 2024, at 1:48 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
>=20
> Hello Mike,
>=20
> Thanks for reading and responding. While your enum does technically =
address some of the issues I am discussing, it does so in a very verbose =
and cumbersome way.
> - First you need the DefaultValue attribute
> - Then you need to use it on each of your `properties`
> - You also need to define an identifier for the const which defeats =
the purpose of using literal strings
> - Then you need to use reflection to access the properties
> - Then you're left with : MyHeaders::create(MyHeaders::CONTENT_TYPE, =
"plain/text", MyHeaders::X_CUSTOM_HEADER,"new_value"); which isn't super =
clear that it's mapping every other value to the one before it.

That is why I wrote that maybe we could consider reducing the verbosity =
and more cumbersome aspects as I proactively recognized it was painful.=20=


That is why I asked about other use-cases. If the only solid use-case is =
HTTP headers we write it once and its done.=20

OTOH, if there are many other use-cases then we could look at adding =
syntax sugar. Adding syntax sugar to languages when boilerplate patterns =
emerge has many benefits: fewer bugs, easier coding, making the language =
more powerful, and etc.

> As for the idea that an object property must be a valid identifier, =
I'm not sure that's correct. Objects can have integer properties =
natively i.e $obj->{1}, and literal string properties are already =
possible when you cast an array to an object

Yes, that was pointed out to me.=20

I was thinking more about the PHP language for language parsers syntax =
when I wrote that and thinking less about the fact that instances can =
have dynamically assigned properties.  My bad.

> Let me show you a few other use cases i've run into
>=20
> ```php
>=20
>             class Sizes {
>                 public function __construct(
>                     private string $sm,
>                     private string $md,
>                     private string $lg,
>                     private string $xl,
>                     private string $2xl, // will throw
>                     private string "10xl", // wouldn't this be nice
>                 ) {}
>             }

Is that really a class that someone would write, with a different =
property for each size and a constructor that required setting each =
size? Or wouldn't they typically have an Enum for the sizes and an array =
property indexed by the enum?

Maybe your example was just to illustrate your desire for a `$2xl` and =
`"10xl"` property?  I see what you want here, OTOH I would not be a fan. =
I'm just as happy to name them `$twoXL` and `$tenXL`, or `$_2xl` and =
`$_10xl` vs. dealing with non-identifiers in declared property names.  I =
get that is not what you want, but realize I am not the decider, I am =
just representing one person's opinion, and I can't even vote on RFCs, =
so there is that. =C2=AF\_(=E3=83=84)_/=C2=AF

>             function htmlElement(string $tag, string $content, =
string|bool ...$attr) {}
>             htmlElement("div", "Hello, world!", class: "greeting", id: =
"greeting", "data-foo": "bar");

I did not grasp the use-case you are showing here because the one in =
your original email included using non-identifiers as parameter names so =
I conflated your two proposals as being one.

In the case you presenting here =E2=80=94assuming I understand what you =
are proposing =E2=80=94 I would likely be in favor of something like it. =
That is if it were orthogonal and not requiring of your first proposal =
i.e. in its own RFC.=20

Taking what you have I would expect something more like the following =
but where `[HtmlAttribute]` is my placeholder for a syntax that would =
specify that zero or more named parameters be collected and assigned by =
property name to the object `$attr` of type `HtmlAttribute` =E2=80=94 =
bikeshed away on that syntax =E2=80=94, and to assign to arrays you =
specify the array index in the named argument, e.g. `data["foo"]`:

class HtmlAttribute {
   public string $_class;
   public string $id;
   public array $data;
}
function htmlElement(string $tag, string $content, [HtmlAttribute] =
...$attr) {}
htmlElement("div", "Hello, world!", class: "greeting", id: "greeting", =
data["foo"]: "bar");

Alternately if you were not envisioning the mapping to an object a =
similar feature could just be way to use a function to collect  =
arbitrarily names parameters into an array, e.g.:

function htmlAttributes(string|int ...$attr) {}
htmlAttributes(class: "greeting", id: "greeting", data["foo"]: "bar");

The above would collect the args into an array `$attr` shaped like this:

array(
   "class" =3D> "greeting",
   "id" =3D> "greeting",
   "data" =3D> array(
     "foo" =3D> "greeting",
   ),
);

Actually, it would be nice if PHP offered both options.

> - Then you're left with : MyHeaders::create(MyHeaders::CONTENT_TYPE, =
"plain/text", MyHeaders::X_CUSTOM_HEADER,"new_value"); which isn't super =
clear that it's mapping every other value to the one before it.


BTW: it could currently be written like any of the following:

// 2-element arrays represents name-value pairs
public static function create(string ...$headers): self {...}
MyHeaders::create(
	[MyHeaders::CONTENT_TYPE, "plain/text"],=20
	[MyHeaders::X_CUSTOM_HEADER,"new_value"]
)

// 1-element arrays w/key and value represents name-value pairs
public static function create(string ...$headers): self {...}
MyHeaders::create(
	[MyHeaders::CONTENT_TYPE =3D> "plain/text"],=20
	[MyHeaders::X_CUSTOM_HEADER =3D>"new_value"]
)

// 1-element array w/multiple elements represents name-value pairs
public static function create(array $headers): self {...}
MyHeaders::create([
	MyHeaders::CONTENT_TYPE =3D> "plain/text",=20
	MyHeaders::X_CUSTOM_HEADER =3D>"new_value"
])

Alternately imagine some syntax sugar that allows dropping the =
`MyHeaders::` from the enum reference when a parameter is declared to be =
an instance of that enum:

// Objects represents name-value pairs
Header(MyHeaders $header, string $name):array {...}
public static function create(Header ...$headers): self {...}
MyHeaders::create(
	Header(CONTENT_TYPE, "plain/text"),=20
	Header(X_CUSTOM_HEADER, "new_value")
)

Finally imagine adding a feature that allows specifying that a parameter =
is the result of a function call give brace enclosed parameters where =
`Header(*)` is my placeholder syntax for bikeshedding, e.g.:

// Objects represents name-value pairs
public static function create(Header(*) ...$headers): self {...}
MyHeaders::create(
	{ CONTENT_TYPE, "plain/text" },=20
	{ X_CUSTOM_HEADER, "new_value"}
)

#fwiw

-Mike=