Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115004 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18600 invoked from network); 22 Jun 2021 07:48:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Jun 2021 07:48:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B9E2E1804D0 for ; Tue, 22 Jun 2021 01:06:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 22 Jun 2021 01:06:30 -0700 (PDT) Received: by mail-qt1-f181.google.com with SMTP id j12so962258qtv.11 for ; Tue, 22 Jun 2021 01:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EKTM5TJYxfT2zS1aD88wLMZkgk9O1r13fZhDbVgbPHU=; b=T1idnS80m9omgmOc0h+uUDk5V3yvQylJfJv0IUxh4Ji7PPlOyHIKBmy9FS8LJoMgX5 PI+xXSpW4OKTT/QR33mHYu/qpA3MttwealyXDRW3Opo6xxjAA5r+2+yXxUxLQICoXD1Z z5BQyCWyi8MLMoUNYUo2cfkO1YsjJ6czaJ0HNTE9GSvqXQxKZWJJqcpCs9LcKXRk9/Ql ez2iJzb3tai0ayzqNjpKYPVkrHjtjF6DYUrWaZu5zruvpE+UtWQtQY0tuDPp9st3NheM ImLRa0oZHiVmaqGMapDYYil1MYnkdUhvx+zk/fCe317BAd8sdpcw3RnIVbaG3ny5DJRA EzBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EKTM5TJYxfT2zS1aD88wLMZkgk9O1r13fZhDbVgbPHU=; b=Tt0n+ZCS83ljJ/GVX5W5ttpmJ4X+RzWZQlfvbFZSKQSxWZQHzq/iEb//eL5LfXwdVe s8I/yDlKxjmcPRJ4Rsi0eJu1gJ4n2f86gdBh8TsOAMW9uIotbMTDIEMtl33Y2VGC8hfH hRbU2Zt5r46NVuQ+J4QN4QdRT0xKSK7R/4/5LJx5jG37e93dWpy/X+EpnY02f1J7VyQ0 4j9F2E6sNEr4kCxiaX/Byr9zGLfMvFsWFkMuM7N2woli4kfjoMkRlsL4IiOO+nHYtrQG v8vaFoxAZSD/f59/wBUcaOevA1fMxT2ZAteA79zydwk16ssf71Gas7yaZ5OlASp7dptU xpmw== X-Gm-Message-State: AOAM530w6DIbu4qQox997kNRVeqeNhAnqVkD4LnLsU+lq0cCrCPSrsk0 ciH/SOzSa8PmkbG9jU4XeKf33Q== X-Google-Smtp-Source: ABdhPJzsBLwfiuDgz7WQQstpgrWrU0B+rUliaXMqv/T6GghQKndh419vKfC3YmjTcH3XsXeo2FEGGQ== X-Received: by 2002:ac8:67d5:: with SMTP id r21mr2402864qtp.92.1624349189331; Tue, 22 Jun 2021 01:06:29 -0700 (PDT) Received: from [192.168.1.10] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8]) by smtp.gmail.com with ESMTPSA id o123sm12343047qkd.6.2021.06.22.01.06.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Jun 2021 01:06:27 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_75CEEA4C-70EB-4CC2-9DF8-D5CE424BE52C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 22 Jun 2021 04:06:25 -0400 In-Reply-To: <7f2da982-e29b-ccca-bddc-24ae7f4b0390@gmail.com> Cc: php internals To: Rowan Tommins References: <7f2da982-e29b-ccca-bddc-24ae7f4b0390@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Subject: Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_75CEEA4C-70EB-4CC2-9DF8-D5CE424BE52C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 21, 2021, at 1:34 PM, Rowan Tommins = wrote: >=20 > 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' =3D> = expr]`. >=20 > 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. >=20 > 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. =20 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 =E2=80=94 as = Tyson also did =E2=80=94 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 =E2=80=94 because arrays are so = ubiquitous in code in the wild =E2=80=94 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? >=20 >> This is useful for shortening long arrays where the keys are known = literals, >> e.g. >>=20 >> ```php >> return [success: true, data: $data, cursor: $cursor]; >> // is equivalent to the following, but shorter: >> return ['success' =3D> true, 'data' =3D> $data, 'cursor' =3D> = $cursor]; >> ``` >=20 > Although common, this is not a good use of arrays; if your keys are = "known literals", they should be fields of some object: >=20 > 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: >=20 > return new class(success: true, data: $data, cursor: $cursor) { public = function __construct(public bool $success, public array $data, public = CursorInterface $cursor) {} }; >=20 > Brainstorming, we could perhaps extend property promotion into the = "new class" clause, so that you could write this: >=20 > 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.=20 ---- NOW, all that said, I am not sure I will support this change to arrays = proposed by Tyson. =20 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 =3D> {=20 success: true,=20 array data: $data,=20 CursorInterface cursor: $cursor=20 }; } 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 =3D> {=20 success: true,=20 array data: $data,=20 CursorInterface cursor: $cursor=20 }; } 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. --Apple-Mail=_75CEEA4C-70EB-4CC2-9DF8-D5CE424BE52C--