Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111588 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 88177 invoked from network); 17 Aug 2020 16:45:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Aug 2020 16:45:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B439218054D for ; Mon, 17 Aug 2020 08:45:58 -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 NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004083.outbound.protection.outlook.com [40.92.4.83]) (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, 17 Aug 2020 08:45:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QF5OHvXBvla+vtxmjYvYUiSo5K6j95PJNUawi+qmHDWHWjEHtdpfel4/EdVm0bc5bdKxy+pPQeR0ORmwMPv8yP3eoOhpLYFTIwfbfc9eMS0yOjL2cWWmr1QCIqbX5uts7tcZyh+vI9ZZx9D2lIPXH0l2NstM6y8dPF+kyq2QP4JvR0o7WK/0mSCVz7KlRcDqyPRUfFJYnJUK+gD/h2BHkEckQD6jjoNdqWuXkKxLTaMdduF7gWG+jJpaila5y08bDXBZg5ZFUuYueUBhEGjp8v7JFrKGmsOGrEVmGGt/CxaugepKPJ4UEb17MaeOc2qXKDoB1HmhZ9oyr7Zdn+qYtg== 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=Ih9DXNl5zaPeTzFKW4fXFrySCVTAdWlTZVLa3wM/54o=; b=QOyTKHEbtBp86mAMqqVIiZypqPyXj0R7MJimgf3ChKpCb3Jqyyk7FGlddLu/1WW7B38A9at5PznQ2LvHXbpPbePSVqYwSrwfrG8eSmWFLGERmJyEpgEoXS8ze/kr1526L+411bbg9eHWZ3aN8C176VHAGUYGtptzFjbYOgSFyCGERCMUf56OTmNA8cKEJRYdZX+ZCK3VlokYfXzY/iWE2X46VnqWSGT6DEmYX/o9fHhfqk+hxDnKrZHHe+w17E4uOvlk50NiW8+PHB3Xiartm9kqJ5pdmXajDFE0NBnW84NitMM15rZmx9o0UmuGy+GxNehbC+4k6JVCWMa3ozaJ1w== 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=Ih9DXNl5zaPeTzFKW4fXFrySCVTAdWlTZVLa3wM/54o=; b=FfBFIGvSEHpWVjW2PAOKzYNsnxZFNp0J+TeZZGicA9H40y2FOrFbWMBxB4W3RhFdYeQcWSPicrN13r/fwEWSfQJtxItz0TJHvwBsJtvDKMdVfiz6Ozd7NJQT7Qfnzls3Pgxt1xSo7UIs/CS5RsmYhWIcqQRV7vOMbx0YaMjGDGnH9WLcTJFWTKXah9fU2TSXwtV8AY5qngT3B3TOXHp4PDhfiMWKnwO1N3RBzJQ9RKFFHO/+mFl2+qp24EE27B03Fcjww+H0u1itGGNl39AKbg1+Ec4634FxqJqXRK9nT0LYlLYhmixEsq3vsiWmSEmMzkMiVZpJONocdlRjvR7wqg== Received: from DM3NAM02FT013.eop-nam02.prod.protection.outlook.com (2a01:111:e400:7e71::44) by DM3NAM02HT183.eop-nam02.prod.protection.outlook.com (2a01:111:e400:7e71::284) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Mon, 17 Aug 2020 15:45:56 +0000 Received: from BYAPR05MB6535.namprd05.prod.outlook.com (2a01:111:e400:7e71::42) by DM3NAM02FT013.mail.protection.outlook.com (2a01:111:e400:7e71::382) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Mon, 17 Aug 2020 15:45:56 +0000 Received: from BYAPR05MB6535.namprd05.prod.outlook.com ([fe80::fc6c:38b0:fa18:f355]) by BYAPR05MB6535.namprd05.prod.outlook.com ([fe80::fc6c:38b0:fa18:f355%7]) with mapi id 15.20.3305.023; Mon, 17 Aug 2020 15:45:56 +0000 To: Benjamin Eberlei CC: Derick Rethans , PHP Developers Mailing List Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 Thread-Index: AQHWamWKUBRwNDrYsUOzfoBQKi8o6Kk6jJOAgAEDLLaAALqdAIAADgONgAAfNXyAAAfBAIAAAf0g Date: Mon, 17 Aug 2020 15:45:56 +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:C27DEE7875D0ADAB65BA82922483B490E5E2BB49762B921EC491EA96045261AB;UpperCasedChecksum:F1CF296C3B0B4372D0B80E62D25D5E870E1F3CAB045D1041DAD1928BCDBEDEC6;SizeAsReceived:7488;Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Ugx5ia6zUtopq1mAXDYQnQyM2ApD0e3P] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 4938d367-cf92-4d8b-a9bb-08d842c4a18e x-ms-traffictypediagnostic: DM3NAM02HT183: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U4poCf00Op3DZaWxkFf4CguLtMbZ3r5Vjcq+wxBzob48e/rihIO7l3ctu3xZDrclvmkHG3FiLCPhCZUdwrcymIsH2yZd5yloM0WSy4sIRsMn/BFW9f27iVRgRAa+qlx1OQ+IEvl5iSd/Yniw6uLAGl05TX3TNmkSe8L2X3G0aKwitjx2wBC41PeyAkQng+J00AMB8wcxs3H56hy80q5Hcw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:;DIR:OUT;SFP:1901; x-ms-exchange-antispam-messagedata: B4JPODQdaiuvGqOpBf5/qLmHpRbyphSekv6dptDVEWYQDjtbNnFMRmdTbpMXsZjU5UbyiUPw+xnFWnWt7v9ZjNpCWTx38BNvAX8UpK3pR9DZXSSti5xgMrtlTDYzUOLlvRu4Tt1OVN09TXqbtnrMbQ== 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: DM3NAM02FT013.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 4938d367-cf92-4d8b-a9bb-08d842c4a18e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 15:45:56.3420 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM02HT183 Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: theodorejb@outlook.com (Theodore Brown) On Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei wro= te:=0A= > On Mon, Aug 17, 2020 at 5:14 PM Theodore Brown w= rote:=0A= > > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:=0A= > > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:=0A= > > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:=0A= > > > > > ## Potential Future Benefits of Enclosed Delimiter Syntax?=0A= > > > > >=0A= > > > > > The RFC shows an example of a potential "simpler" attribute using= a=0A= > > > > > string instead of a class name. I honestly have no idea what this= is=0A= > > > > > supposed to do or what benefit it would have over normal attribut= es.=0A= > > > > >=0A= > > > > > The concept of attributes being a class name with optional argume= nts=0A= > > > > > has been proven over many years by its use in docblock annotation= s,=0A= > > > > > and if there was some deficiency in what this syntax allows it se= ems=0A= > > > > > like we would have discovered it by now.=0A= > > > >=0A= > > > > I agree on just the string, but a closure would make 100% sense for= =0A= > > > > a decorating feature. Javascript and Python "Attributes" work as=0A= > > > > decorators, i.e. they get called around the decorated function.=0A= > > > >=0A= > > > > It is not a completely unrealistic feature to think off:=0A= > > > >=0A= > > > > @[fn($x) =3D> syslog(LOG_INFO, "Called function foo with x: " . $x)= ]=0A= > > > > function foo($message) {}=0A= > > >=0A= > > > As I understand it JavaScript decorators do not use anonymous=0A= > > > functions for decorators like this, though. Instead you would make a= =0A= > > > named function and apply it with `@myFunc()` before the decorated=0A= > > > function or class.=0A= > > >=0A= > > > Presumably we could accomplish the same thing in PHP with e.g. an=0A= > > > `__invoke` method in the attribute class, without complicating the=0A= > > > attribute syntax itself.=0A= > > =0A= > > One other thought on this. I agree that decorators are not a=0A= > > completely unrealistic future feature. However, it must be noted that= =0A= > > both JavaScript and Python use the `@Attr` syntax for decorators, and= =0A= > > the lack of an end delimiter in no way precludes this usage.=0A= > =0A= > Yes they support decorators with @, but they don't support metadata.=0A= > =0A= > With this syntax its either or, because from @Attr only you cannot=0A= > decide if its a decorator or a metadata attribute.=0A= > =0A= > It would not work by detecting __invoke on the Attribute, because=0A= > the whole architecture of Attributes is based on deferring=0A= > autoloading until Reflection*::getAttributes(). But when you use=0A= > decorators, you would need to know this at runtime, so the=0A= > zend_attribute datastructure would need to know its not an metadata=0A= > attribute, but a decorator.=0A= =0A= Hi Benjamin,=0A= =0A= That's true. Due to deferred loading we would need some kind of=0A= new syntax to denote checked attributes or decorators, *regardless=0A= of whether the attribute syntax has an end delimiter*. As I've=0A= suggested before, we could potentially denote checked attributes=0A= in the future like this:=0A= =0A= @@!Attr("some val")=0A= function foo() {...}=0A= =0A= I still believe that using an inline closure attribute syntax like=0A= the example in the RFC would not be a good solution for decorators,=0A= as it reduces reusability and readability, and would prevent applying=0A= a decorator that includes metadata.=0A= =0A= Best regards, =0A= Theodore=