Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112077 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 70060 invoked from network); 19 Oct 2020 16:00:37 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Oct 2020 16:00:37 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4485B1804B5 for ; Mon, 19 Oct 2020 08:17:18 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11olkn2058.outbound.protection.outlook.com [40.92.18.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 19 Oct 2020 08:17:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RXEVFKRx5aPeVAtlYbv8Irm01JEsHRVjuLLKg2s+aqt7NiL/R+6t2f+6jNqpSEkcnLWZhUguMcEjyxhB26SRtMDIieV85H18jtY1Um2ZiuTlNa9635rrZbb2t6HR9IzjcLdabwU03JY6VaPBkUE6TEyqE51Exn3ane4NNbsyK4IESyONh5AJ5oXgfaFRCIS4lCLyecEKTP4qPYidchhhNW3EtfItNGaLvGCPGQI5MGKGrKA6zR0LjAK3papJlDWEnvXR/tqg3hZ0cUSgewQZzXCYJTjzcYN1LSK/BBjeuNXger/mVsvGxhPRI8knpe8lTK+6HsCfTDb2U+V5BLfgng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zYW2NVeUjPLVw0BvJ10dSZy9wr2SrMR38fkFdL4rKZ4=; b=Lmc8yoJDSiSOaObABYPLkPllm9iEYOGLTMCymoclmuAwUrSNZty81HijEqNaUgbjrHR+zhJ3rtxEc6ixRxmjv+4TaRT8mAEl7OVym/pFqJ7wr3AVoyYS6ztb+Uj5p6knVxLbzaw20u6tj0banu4V7z/cHIS3GdIGFnIUqIlauNC35lZSR+11quWpa4yvQbDIufcEQjPHn1xcSSdqZzav09lUJvi6GLlUK/TYyljci28ZrCp37slX1WKCoSMPgsWeFpIK06GpNToQ+u/3mueMGhXjNoUShOP7LEKWji7HvKB9FHh+n26KlMupa+WPcc+jiLyZPfIFGsbqq+8NyLE5FQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zYW2NVeUjPLVw0BvJ10dSZy9wr2SrMR38fkFdL4rKZ4=; b=Q142o21Z2oNs/4dAekdjpit0KjCBAnyXa6ncmTcLjUTOR2xZqGy8UA+TViJQ68yOkLCb2oCdlPqiRdX6m3XcmcbLEmGwmQ9/ydA+GROq4cQ3sahM+dfewUTSKHqohXuDWnLSVWh7EzENwejfUliU7g00PIwXeU3vdHlqk+3jPZUd7BsUJ/4kZsbdALJ4+VjPXdj6omJ42D2K+MVDpj6z4iM992L5/cb6kG9yO6pj0R1MRImBxAwLwodrBQSKmQigxz+wC03vDEj7xebvmgbulOzXQ6OIBklDKKIAkNtpFT/Qz6JxDyGXRWZfcMgZtBFa5ok+kCDxLAXkMK+bX8Xzbg== Received: from CO1NAM11FT052.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::43) by CO1NAM11HT205.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Mon, 19 Oct 2020 15:17:12 +0000 Received: from BYAPR05MB5478.namprd05.prod.outlook.com (2a01:111:e400:3861::4d) by CO1NAM11FT052.mail.protection.outlook.com (2a01:111:e400:3861::225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Mon, 19 Oct 2020 15:17:12 +0000 Received: from BYAPR05MB5478.namprd05.prod.outlook.com ([fe80::1520:24a9:8177:7990]) by BYAPR05MB5478.namprd05.prod.outlook.com ([fe80::1520:24a9:8177:7990%5]) with mapi id 15.20.3499.009; Mon, 19 Oct 2020 15:17:12 +0000 To: Nicolas Grekas , Benjamin Eberlei CC: Nikita Popov , PHP Internals List Thread-Topic: [PHP-DEV] List of attributes Thread-Index: AQHWlKduqAD4JLWTfUSbO6DleNAbtql92cYAgAAq64CAATgcAIAJ4ESAgBYMm8o= Date: Mon, 19 Oct 2020 15:17:12 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:7A68C9299B5D68EE6715BED42B9DC96D9E1A4080CDB9033C7124BCBFCD0B8F70;UpperCasedChecksum:603E78751A4D6374F2526ECE79E82CFD2122B8B4805740E708D4594229601ADA;SizeAsReceived:7262;Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [U+mc8rmLP7meU4/AGmh31YwdolmoZhHl] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: c4b8601d-a8a1-4ba9-aab3-08d874420e2c x-ms-traffictypediagnostic: CO1NAM11HT205: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BjPAdjMfdqdPytTHzc4zvZz/z8OZQSEhrUUTG8dadB/f/UQWVXzNbafZxoxtxU6Q37MyObQVn2PwJ0xn9qgAhGrFI0IpMye8BF1w7LY2QZcQNOZaz1x2u569Yu0khwhmTc+KxiPKSZoq914STw9pQlLVXeeVEyZsliAjcMNvbH+98gfwTL7J6CQPw533eZ/uyMGByrKNl/F3blky6l4yT7DDkL2d8ci4PESPWgnrrr/DzMe8WChc69G7saElDi7W x-ms-exchange-antispam-messagedata: ZWertIsC3rUaL+HFyLRiJ2EjAK8jAbg3dyiFUCEB07UHRvh3hAQVRIzwDxxfEb2/gocQDXmpVJsH9xtymkmed3Yeat9UZcPnDOuDXm0jL9TXZEgiSpHAVwLuxvhuIUdD2NoGzgLogedQQiIGifIrEg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT052.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: c4b8601d-a8a1-4ba9-aab3-08d874420e2c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 15:17:12.6997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT205 Subject: Re: [PHP-DEV] List of attributes From: theodorejb@outlook.com (Theodore Brown) On Mon, Oct 5, 2020 at 9:24 AM Nicolas Grekas wr= ote:=0A= =0A= >> I'm wondering if the syntax that allows for several attributes is=0A= >> really future-proof when considering nested attributes:=0A= >>=0A= >>=0A= >> *1.*=0A= >> #[foo]=0A= >> #[bar]=0A= >>=0A= >> VS=0A= >>=0A= >> *2.*=0A= >> #[foo, bar]=0A= >>=0A= >> Add nested attributes to the mix, here are two possible ways:=0A= >>=0A= >> *A.*=0A= >> #[foo(=0A= >> #[bar]=0A= >> )]=0A= >>=0A= >> or=0A= >>=0A= >>=0A= >> *B.*=0A= >> #[foo(=0A= >> bar=0A= >> )]=0A= >>=0A= >> The A. syntax is consistent with the 1. list. I feel like syntax=0A= >> B is not desired and could be confusing from a grammar pov.=0A= >> BUT in syntax 2., we allow an attribute to be unprefixed (bar),=0A= >> so that syntax B is consistent with 2.=0A= >>=0A= >> Shouldn't we remove syntax 2. in 8.0 and consider it again when nested= =0A= >> attributes are introduced?=0A= >>=0A= >> I voted yes for syntax 2. when the attributes were using << >>. I would= =0A= >> vote NO now with the new syntax.=0A= >>=0A= >> Nicolas=0A= >=0A= > As far as my understanding goes, if we introduce "nested" attributes, it= =0A= > will be in the form of relaxing constraints on constant expressions, i.e.= =0A= > by allowing you to write #[Attr(new NestedAttr)].=0A= >=0A= > Nikita=0A= =0A= Back when the original `<<>>` attribute syntax was being implemented,=0A= there was an attempt to do just this. But it turned out to be very=0A= difficult to implement, and it was ultimately given up on since it=0A= required significant changes to const expressions. Earlier this year=0A= there was also a poll to gauge interest in supporting function calls=0A= in constant expressions, but most voters opposed it. [1]=0A= =0A= Even if a proposal for relaxing constraints on constant expressions=0A= gains enough support, it's not clear this is the ideal path forward=0A= for nested attributes, since as Nicolas pointed out this wouldn't=0A= have the same lazy-loading semantics as existing attributes.=0A= =0A= Straightforward support for nested attributes was one of my main=0A= motivations for proposing the `@@` syntax in the Shorter Attribute=0A= Syntax RFC, [2] and I had hoped to collaborate on a follow-up RFC to=0A= support nested attributes with the AT-AT syntax. This would allow=0A= existing nested docblock annotations such as Nicolas's example to=0A= translate intuitively to native attributes:=0A= =0A= @@Assert\All([=0A= @@Assert\Email,=0A= @@Assert\NotBlank,=0A= @@Assert\Length(max: 100)=0A= ])=0A= =0A= This would also preserve the lazy-loading feature where these=0A= attribute classes aren't loaded until code calls `newInstance`=0A= on one of the `ReflectionAttribute` objects.=0A= =0A= But then the Shorter Attribute Syntax Change RFC [3] came along and=0A= derailed this plan...=0A= =0A= In theory nested attributes could be supported in the same way with=0A= the `#[]` syntax, but it's more verbose and I think less intuitive=0A= (e.g. people may try to use the grouped syntax in this context, but=0A= it wouldn't work). Also the combination of brackets delineating both=0A= arrays and attributes reduces readability:=0A= =0A= #[Assert\All([=0A= #[Assert\Email],=0A= #[Assert\NotBlank],=0A= #[Assert\Length(max: 100)]=0A= ])]=0A= =0A= But at this point I assume this is the most viable path forward for=0A= nested attributes (barring another syntax re-vote and delay of PHP 8).=0A= I know Derick and Benjamin have stated they aren't in favor of nested=0A= attributes and didn't put any thought into the syntax for them, but I=0A= feel this is unfortunate since nested attributes are an established=0A= pattern with legitimate use cases in existing libraries.=0A= =0A= Best regards, =0A= Theodore=0A= =0A= [1]: https://wiki.php.net/rfc/calls_in_constant_expressions_poll=0A= [2]: https://wiki.php.net/rfc/shorter_attribute_syntax=0A= [3]: https://wiki.php.net/rfc/shorter_attribute_syntax_change=