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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
