Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111366 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22586 invoked from network); 7 Aug 2020 12:05:28 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Aug 2020 12:05:28 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B61281804AA for ; Fri, 7 Aug 2020 04:03:52 -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.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Fri, 7 Aug 2020 04:03:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id DC08410C13A; Fri, 7 Aug 2020 12:03:50 +0100 (BST) Date: Fri, 7 Aug 2020 12:03:50 +0100 (BST) X-X-Sender: derick@singlemalt.home.derickrethans.nl To: Theodore Brown cc: Benas IML , Rowan Tommins , PHP Internals List In-Reply-To: Message-ID: References: <20200806091749.64675445@mcmic-probook.opensides.be> , User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1262399167-1596798231=:7489" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: derick@php.net (Derick Rethans) --8323329-1262399167-1596798231=:7489 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 7 Aug 2020, Theodore Brown wrote: > On Thu, Aug 6, 2020 at 12:30 PM Benas IML wro= te: >=20 > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wr= ote: > >=20 > > > While none of our syntax options are perfect, I believe @@ has the > > > best long-term tradeoffs because: > > > > > > - It doesn't break useful syntax > >=20 > > Fair enough. > >=20 > > > - It is equally or more concise than grouped attributes without > > > adding complexity to the parser/compiler > >=20 > > Are we really going to debate that ~30 lines of code add complexity? >=20 > I don't know how many lines of code it will be, since an=20 > implementation for it has never been finished. The patch currently=20 > linked in the RFC does not implement it. >=20 > Even if we assume the implementation is only about 30 lines, it's=20 > still extra complexity that I don't understand the benefit of. I=20 > sincerely would like to know what advantage there is of grouped=20 > attributes over the `@@` syntax. It was very *specifically* voted for: https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attribute= s1 The complexity is minimal: https://github.com/php/php-src/pull/5928/commits/597688fd5b0a41d23028454b62= ba25f950f35a16 And most of the change is just indentation. You still haven't addressed any of the deficiencies that the other=20 alternatives don't have:=20 https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal > I would agree that `@[]` is more similar than `#[]` is. But arguably=20 > `@@` is still the closest since docblock annotations don't require=20 > being wrapped in array brackets. They're instead wrapped in /** =E2=80=A6 */ though, which also acts like a= =20 grouping structure. > > > - It is aligned with the attribute semantics of the majority of C > > > family languages > > > > In what way `#[]` or `@[]` aren't? >=20 > The majority of C family languages use `@Attr` without an extra end > symbol. PHP isn't C though=E2=80=94hack, C has a function 'creat()', so that argume= nt=20 doesn't really mean much. cheers, Derick --=20 PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug --8323329-1262399167-1596798231=:7489--