Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111938 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 72570 invoked from network); 27 Sep 2020 11:45:42 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Sep 2020 11:45:42 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B92C01804B7 for ; Sun, 27 Sep 2020 03:56:47 -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_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 ; Sun, 27 Sep 2020 03:56:46 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id a9so3721563wmm.2 for ; Sun, 27 Sep 2020 03:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9FRrP3Hn79xwH5nMO2tDZAtR7BZnnudmTyzSPUkIK9Y=; b=EQNPn65jFhheKxtElsJJ6QdCK/h/85DDfTv8WC47yIzsYm3PcCGqVLcJWOlSerZagN yl481xYKU6X6lDWTVDT0F/3r/SjlEm/Hs5ibHK4u9xSLHWWn97FTKi/YgPt8HzUC193A aQpzYXpTDo1pPoINmUY5vIISn7jOzNs+tOkeuCNeC+G/fJK5xYIEcO7pj9nY4K6+Hi7B yT3nFAM/TuasQ9bMRepeoL9LzmZdv1gryi+IoYfjnIg7jJuyYf0b7qF+UKQQd8gIGprk Tov65jHxy1wTK8CsO/G8lYjwfCYuYWeDJNWTXVNsSVBn7ZByTvlsuMz2rVGz/dOVtLQa pT+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9FRrP3Hn79xwH5nMO2tDZAtR7BZnnudmTyzSPUkIK9Y=; b=X6ueTt67om0u21v49xvHk+Zhj9OEkvOStYJOwKEaxMM2HmeFmIdx6UE58IIJi9GVzm M5MpHSsNxKfSZX4BLxu32DHxABBhYnofJB1Qd02dSWzKXiiaD/RQn7guyXIbaV6Eu/ul TuM6th997sSpCl22NDhYz/IAM9KnQrJRB5wqlAWupWUbA2esgvliASM/WJDDhWqpISz9 sL0YTkF9Ds4SbWkSYcu1JwzoVnGT/FptVl4i1n23z29KjIShlABnPGFjeXWUyTaiyLm2 IK2Un2zy7OLeXwided7BBsiXyKoobeODE1PZzzLGl0FXjaP72dFyh9JZWz4W+eDPim5J nH0A== X-Gm-Message-State: AOAM530sJaQ1VwJ2eoo4akrBSh2fBefieJ9cLjY2y41o5D5mRpWZL5jX iE8Zpl9OFmGUTUhP+3zmL/gYjfbNqT95AssSVdyzrA== X-Google-Smtp-Source: ABdhPJzcIE+fT9HT4e3BAv7B8uT0U5ZienBWPXpykjEA6Y8uSPIaaHl0kl8zIWPGU1YiW74q6bcDISGou8p7D2rm4/8= X-Received: by 2002:a1c:23c8:: with SMTP id j191mr6284825wmj.64.1601204203882; Sun, 27 Sep 2020 03:56:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 27 Sep 2020 12:56:33 +0200 Message-ID: To: Nicolas Grekas Cc: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000c91c0605b0496777" Subject: Re: List of attributes From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000c91c0605b0496777 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 27, 2020 at 10:23 AM Nicolas Grekas wrote: > Hi Benjamin, hi everyone > > I'm wondering if the syntax that allows for several attributes is really > future-proof when considering nested attributes: > I feel this question is what an RFC for nested attributes has to weigh. We have established that in practice nested is possible syntax wise. Personally I am not interested in introducing nested attributes, because they would allow a complexity in attribute usage that might be better handled by actual configuration files (XML, JSON, YAML, INI choose your poison). As such I am not looking into working on this addition myself and haven't put any thought into the actual syntax. In general we have not established yet if the support for nested attributes would get a super majority of voters and its increased complexity is the major reason why I opted to leave it out of the original RFC. For Doctrine ORM for example I prototyped this new attribute based driver that flattens the structure so that nested attributes are not needed https://github.com/doctrine/orm/pull/8266 - without making the usage less clear (in my opinion). > > > *1.* > #[foo] > #[bar] > > VS > > > *2.* > #[foo, bar] > > Add nested attributes to the mix, here are two possible ways: > > > *A.* > #[foo( > #[bar] > )] > > or > > > *B.* > #[foo( > bar > )] > I'll throw a few more options into the mix - #[foo(bar())] - #[foo(#bar())] - #[foo(new bar())] > The A. syntax is consistent with the 1. list. > I feel like syntax B is not desired and could be confusing from a grammar > pov. > BUT in syntax 2., we allow an attribute to be unprefixed (bar), so that > syntax B is consistent with 2. > > Shouldn't we remove syntax 2. in 8.0 and consider it again when nested > attributes are introduced? > > I voted yes for syntax 2. when the attributes were using << >>. I would > vote NO now with the new syntax. > > Nicolas > --000000000000c91c0605b0496777--