Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115003
MIME-Version: 1.0
In-Reply-To: <DM6PR07MB6618BFFFCFEE708BBCF5589AF9099@DM6PR07MB6618.namprd07.prod.outlook.com>
References: <DM6PR07MB66186AD1AF40B256C5C3ABA0F90A9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <7f2da982-e29b-ccca-bddc-24ae7f4b0390@gmail.com> <CAGBsUrcc-ujQwo0h+rx8H9ScvBLawkrn66q2rLvB4BfpJfwZdQ@mail.gmail.com>
 <2DF8EE9E-8B83-42C0-898D-550FF36F2943@dafert.at> <DM6PR07MB6618BFFFCFEE708BBCF5589AF9099@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Tue, 22 Jun 2021 09:04:49 +0500
Message-ID: <CAC_PL4zc9z07L-V_-rdDzSAiKKT7CB8cHKPj1HUjg654S+vESA@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)
From: office.hamzaahmad@gmail.com (Hamza Ahmad)

Hi Tyson,

Regardless of what others are saying, I personally like your RFC. The
reasons are following:
1. Because named keys are valid PHP names, they are resolved at the
parsing level. Thus, they will not be validated again and again.
Later, no constants are looked for.
2. At the runtime level, no variable location is done.
3. Since all keys are to be passed as PHP names, both single quoted
and double quoted strings are not dealt with. Similarly, concatenation
operations are not also performed.
4. Because all named keys are strings by default, type checking is not enfo=
rced.
5. `key=3D>value` costs 2 characters without spaces. If a keyboard user,
like me, wants to make its code easier to navigate, it adds two spaces
to either sides of `=3D>` operator. Then, single quoted and double
quoted strings have two extra characters, too! Quotes + spaces +
assignment =3D:
2 + 2 + 2 =3D 6. If your suggested feature is added, 6 will be reduced
to two =E2=80=94 a colon follows a name, and a space follows the colon. Yay=
,
we have formulated a solution that simplifies keyboard navigation.

Yes, the idea of making anonymous classes/objects easier seams also
compelling. Since this is a discussion, I propose to use braces `{}`
instead of brackets `[]` and follow the pattern that Tyson is
suggesting. I know that it is similar to JavaScript, but it will be
different in one regard that it disallows the use of strings
(regardless of whether they are literals).

Because it requires extra effort to perform array-related operations
on objects, I prefer these two syntaxes:
1. `array(a: 1, b: 2, c: 3);`
2. `[a: 1, b: 2, c: 3];`

Best Regard
Hamza Ahmad


On 6/22/21, tyson andre <tysonandre775@hotmail.com> wrote:
> Hi Mel Dafert,
>
>> >I would prefer an improved syntax for creation of anonymous objects. Th=
is
>> >is something which I have been annoyed with, myself.I'd like to see a
>> >simple way of creating anonymous objects with typed properties.
>>
>> Another advantage arrays currently have over anonymous objects is
>> destructuring -
>> if this was (somehow?) also made possible with objects, this would be th=
e
>> best of both worlds.
>> (Returning multiple named values from a function is also mentioned in th=
e
>> use-cases of the RFC.)
>> I know this works:
>>
>> ```
>> [ "foo" =3D> $foo, "baz" =3D> $baz ] =3D (array) $object;
>> ```
>>
>> (Alternatively also using get_object_vars() instead of casting.)
>> But we both have to convert to an intermediate array again, and lose the
>> type information of the object (eg. for static analysis), so this could
>> also be
>> made more ergonomic if we want to go down the anonymous object route.
>
> Ideas for syntax:
>
> There's `object(foo: $foo, 'hyphenated-key' =3D> $key) =3D $object;`,
> but that would require making `object` a reserved keyword, and it current=
ly
> isn't one.
>
> - I had suggested using `$x =3D object(foo: $foo);` as a shorthand for `$=
x =3D
> (object)['foo' =3D> $foo];`
>   at some point. Feedback was negative for largely unrelated reasons
> (stdClass in general). https://externals.io/message/112082
>
> `object{foo: $foo}` seems similarly unambiguous by requiring at least one
> property but would also require a new reserved word
>
> Or `({ foo: $foo }) =3D $object;` - On second thought, I'm against that -=
 that
> is very likely to conflict with possible future proposals to parse block
> expressions.
> (e.g. getting parsed as a label for a goto followed by returning the
> variable $foo.)
>
> `list{ foo: $foo } =3D $object` is unambiguous, I guess
>
> `(object)['foo' =3D> $foo] =3D $object;` was another idea but that wouldn=
't even
> work.
> It's already valid syntax that is parsed as casting an assignment to an
> object.
>
> `->{'foo' =3D> $foo} =3D $object;` may be parseable but doesn't make much=
 sense.
>
> Thanks,
> Tyson
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>