> On Jun 21, 2021, at 1:34 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 21/06/2021 17:54, tyson andre wrote:
>> 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.
>>
>> ```php
>> 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.
