[PROPOSAL] Bare name array literals (again)

Hi Tyson,

Interesting proposal, but I was going to reply with the exact same response
as Rowan. Why not use DTOs for such purposes? Arrays have rather limited
use cases. If you need to return multiple results from a function then you
should return an object with typed properties.
I don't like the idea of adding yet another syntax for creating arrays,
especially one with limitations. If your array keys contain spaces or
special characters then you need to use the current syntax. Adding to the
fact that arrays have no type safety, I don't see much use for the newly
proposed syntax.

I would prefer an improved syntax for creation of anonymous objects. This
is something which I have been annoyed with, myself.I'd like to see a
simple way of creating anonymous objects with typed properties.

Regards,
Kamil

In every place where key is a valid php identifier
(e.g. can be used in PHP 8.0's named parameters),
I propose to allow [key: expr] to be used instead of ['key' => expr].

This is an immediate "no" from me: it multiplies the ways to write the
same thing from 2 to 4, in order to save a few bytes, in a few instances.

I think this is something that Douglas Crockford got absolutely right
when he simplified JavaScript object syntax to formalise JSON: every
valid key can be represented as a quoted string, so if the quotes are
always there, you don't need to remember a list of rules about reserved
words, allowed characters, etc.

This is useful for shortening long arrays where the keys are known literals,
e.g.

return [success: true, data: $data, cursor: $cursor];
// is equivalent to the following, but shorter:
return ['success' => true, 'data' => $data, 'cursor' => $cursor];

Although common, this is not a good use of arrays; if your keys are
"known literals", they should be fields of some object:

return new Result(success: true, data: $data, cursor: $cursor);

If you don't want to declare a class (yet), you can use an anonymous
object. Rather than yet another way to write arrays, it would be great
to have some more powerful syntax for those; currently you'd have
something like this:

return new class(success: true, data: $data, cursor: $cursor) { public
function __construct(public bool $success, public array $data, public
CursorInterface $cursor) {} };

Brainstorming, we could perhaps extend property promotion into the "new
class" clause, so that you could write this:

return new class(public bool success: true, public array data: $data,
public CursorInterface cursor: $cursor) {};

I agree with Rowan on both points. The issues this would supposedly solve a better solved by continuing to work on making real-objects easier to work with. PHP 8 made huge strides in that area. Making anon classes easier would be the next logical step.

Also, Mel mentioned destructuring. Ilija has partially-finished work on a pattern matching operator that would include destructuring here:

https://wiki.php.net/rfc/pattern-matching

It's not going to make it into 8.1, sadly, but hopefully that or something like it would make it into 8.2.

--Larry Garfield

Hi Rowan Tommins,

This is an immediate "no" from me: it multiplies the ways to write the
same thing from 2 to 4, in order to save a few bytes, in a few instances.

It's from 4 to 6 if you include single quoted strings vs double quoted strings.
If linters and automatic fixers were set up for a project to enforce it (e.g. phpcbf),
there would only be one way that literals would be used in a project either way.

I think this is something that Douglas Crockford got absolutely right
when he simplified JavaScript object syntax to formalise JSON: every
valid key can be represented as a quoted string, so if the quotes are
always there, you don't need to remember a list of rules about reserved
words, allowed characters, etc.

It's the same rules as parts of identifiers or variable names.
I don't think there are any reserved words for named params or this proposal(default, etc. are allowed despite being keywords)

What makes sense for a serialization format which will have hundreds of encoders/decoders may not make sense for a programming language.

This is useful for shortening long arrays where the keys are known literals,
e.g.

return [success: true, data: $data, cursor: $cursor];
// is equivalent to the following, but shorter:
return ['success' => true, 'data' => $data, 'cursor' => $cursor];

Although common, this is not a good use of arrays; if your keys are
"known literals", they should be fields of some object:

return new Result(success: true, data: $data, cursor: $cursor);

If there is only a single place where an array with those keys is returned,
or if dynamic properties get added later,
then creating a class may not be worth it.

Developers would have to switch between files and keep track of which classes were
ordinary data storage and which had side effects or transformed parameters.

If you don't want to declare a class (yet), you can use an anonymous
object. Rather than yet another way to write arrays, it would be great
to have some more powerful syntax for those; currently you'd have
something like this:

return new class(success: true, data: $data, cursor: $cursor) { public
function __construct(public bool $success, public array $data, public
CursorInterface $cursor) {} };
Brainstorming, we could perhaps extend property promotion into the "new
class" clause, so that you could write this:

return new class(public bool success: true, public array data: $data,
public CursorInterface cursor: $cursor) {};

I think anonymous objects would benefit some use cases but would not be useful for every use case (e.g. short single-file shell scripts),
though the typed properties and constructor property promotion are definitely convenient.

Also, with no common interface between those anonymous classes,
using just anonymous classes would be writing functions that accept any object or return any object,
which would be error prone and hard to analyze.

Those anonymous classes wouldn't have any ancestors in common for instanceof checks.
Also, if there were optional parameters, that can be represented in non-standard JSDoc supported by static analyzers
(success: bool, data?: array, cursor?: CursorInterface, errorMessage?: string),
but that wouldn't be represented in an anonymous class
(setting a property to null is not the same as omitting it).

This reminds me of https://docs.python.org/3/library/collections.html#collections.namedtuple
but I don't plan to propose that (something similar could be done by validating all property names are valid,
getting the sha1 of the ordered list of property names to choose a class name,
and optionally setting properties to readonly (if the RFC passes) and forbidding dynamic properties,
and extending some common interface).

Thanks,
Tyson

In every place where key is a valid php identifier
(e.g. can be used in PHP 8.0's named parameters),
I propose to allow [key: expr] to be used instead of ['key' => expr].

This is an immediate "no" from me: it multiplies the ways to write the same thing from 2 to 4, in order to save a few bytes, in a few instances.

I think this is something that Douglas Crockford got absolutely right when he simplified JavaScript object syntax to formalise JSON: every valid key can be represented as a quoted string, so if the quotes are always there,p ...

That is one way to look at it.

Another way to look at it was Crockford's regrettable decision to optimize for the uncommon case by imposing tedium on developers and making reading of JSON files even harder for end-users than developers has created an unfortunate legacy that we can likely never correct given the ubiquity of JSON at this point. That decision was probably the initial impetus for JSON5, even, which unfortunately can't get widespread adoption because of JSON classic's ubiquity.

But I digress. And the reason I digress is to contrast — as Tyson also did — the JSON the serialization form with the programming language form. Javascript itself supports object initialization without having quotes around the identifiers. And unless I remember wrongly, serializing the JSON object was the spark that turned into JSON.

Meanwhile back at PHP, one of the most annoying and poor developer experience aspects of working with PHP — because arrays are so ubiquitous in code in the wild — is the requirement for those damn quotes around array indexes, and especially that array indexes are not implemented as symbols so that we can get some "compile-time" checking of indexes in our IDEs and linters and even PHP itself.

you don't need to remember a list of rules about reserved words, allowed characters, etc.

Having to remember the same rules for symbol identifiers hardly seems to be a burden for a developer to me.

Also, you used etc. but I cannot think of anything else. Is there something you did not include?

This is useful for shortening long arrays where the keys are known literals,
e.g.

return [success: true, data: $data, cursor: $cursor];
// is equivalent to the following, but shorter:
return ['success' => true, 'data' => $data, 'cursor' => $cursor];

Although common, this is not a good use of arrays; if your keys are "known literals", they should be fields of some object:

return new Result(success: true, data: $data, cursor: $cursor);

Except that arrays in PHP can do things objects cannot do in PHP. So your assertion as an absolute is not valid.

To start with, and most important for the immutable-envious developer world is that arrays are passed by value. Unless and until we have an object equivalent for passing by value you cannot authoritatively say "your fields should always be in an object."

Also, as noted by Kami and acknowledged by Larry, there are many things you can do with arrays you cannot do with objects such as destructuring.

If you don't want to declare a class (yet), you can use an anonymous object. Rather than yet another way to write arrays, it would be great to have some more powerful syntax for those; currently you'd have something like this:

return new class(success: true, data: $data, cursor: $cursor) { public function __construct(public bool $success, public array $data, public CursorInterface $cursor) {} };

Brainstorming, we could perhaps extend property promotion into the "new class" clause, so that you could write this:

return new class(public bool success: true, public array data: $data, public CursorInterface cursor: $cursor) {};

Let's compare your suggestion with the following from a readability and also developer quality-of-life perspective:

return [ success: true, data: $data, cursor: $cursor ];

YES, there are benefits you get with the approach you mention, but readability and developer experience are definitely not in that set of benefits.

NOW, all that said, I am not sure I will support this change to arrays proposed by Tyson.

I might, but I would like to understand Tyson's use-cases first where he would prefer to need an array instead of an object if objects instantiation were made easier, and more importantly, why could objects not be used?

-Mike

P.S. While I wanted to close with a request for Tyson to explain, I also want to mention I would likely be a lot more interested in is innovation in the area of object initialization, implicit typing and implicit class declaration.

Consider if the following could create an instance of an anonymous class with an implicitly-typed public boolean property success, and array property data and a CursorInterface property cursor? Wouldn't that be a lot better than the very explicit declaration of the anonymous class syntax proposed?

function Foo() {
....
return { success: true, array data: $data, CursorInterface cursor: $cursor };
}

Frankly I would also like to see it not create an anonymous class but be able to name the class then and there, e.g. something like this where FooReturn is automatically declared here as a class with default public properties:

function Foo() {
....
return as FooReturn => {
success: true,
array data: $data,
CursorInterface cursor: $cursor
};
}

These would primarily be value objects, so we could limit them to just properties. It would also make a readonly attribute useful, e.g.

function Foo() {
....
return as readonly FooReturn => {
success: true,
array data: $data,
CursorInterface cursor: $cursor
};
}

Which actually brings up an interesting question. Why can't we have declared array types? Aren't they often used no-declare value objects? At which point, why is there a difference between array usage and object usage other than parameter passing type. Why can't we use foreach and [] on objects, and -> on arrays?

I'm asking these questions in hopes others will consider out-of-the-box thinking when exploring what might be for PHP.

Hi Christian Schneider,

return [success: true, data: $data, cursor: $cursor];
// is equivalent to the following, but shorter:
return ['success' => true, 'data' => $data, 'cursor' => $cursor];

Just a little side-note: A while ago I proposed a 2-line-patch to allow :$foo as a synonym for 'foo' => $foo.

This allows for
        return ['success' => true, :$data, :$cursor];
which is both shorter and removes repetition while keeping the variable usage $data and $cursor visible.

I know that this has been shot down before but I couldn't resist mentioning it in this context, sorry ;-)

I'd also implemented the same thing at https://github.com/php/php-src/pull/6635 and reverted it - didn't see that when the PR was first created

It had also suggested :$var or =$var as shorthand for var: $var,
but this is going to be left out of this proposal
https://externals.io/message/101698 has mostly negative feedback on a recent proposal (and there are multiple syntax candidates)

That was left out - I expected it would get less votes than just var: $var for reasons mentioned in https://externals.io/message/101698

Based on past RFCs I've seen, I'd assume an RFC would fail if most feedback was proposing alternate solutions or arguing against it, like it is here.
And voting results for https://wiki.php.net/rfc/bare_name_array_literal were mostly negative.
I'd hoped named arguments using the same syntax might raise interest in this, but it doesn't look like it so far.

E.g. short functions in https://externals.io/message/113751 had some positive feedback, but still got less than 2/3 votes

Thanks,
Tyson