Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92639 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27325 invoked from network); 22 Apr 2016 12:25:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Apr 2016 12:25:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=tpunt@hotmail.co.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tpunt@hotmail.co.uk; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.co.uk designates 157.55.0.213 as permitted sender) X-PHP-List-Original-Sender: tpunt@hotmail.co.uk X-Host-Fingerprint: 157.55.0.213 dub004-omc1s14.hotmail.com Received: from [157.55.0.213] ([157.55.0.213:49596] helo=DUB004-OMC1S14.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/94-14036-71F0A175 for ; Fri, 22 Apr 2016 07:46:32 -0400 Received: from DUB129-W57 ([157.55.0.237]) by DUB004-OMC1S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 22 Apr 2016 04:46:27 -0700 X-TMN: [0+rspFkvHcH5v9Ju05/nxT5Nt6D9KAoK] X-Originating-Email: [tpunt@hotmail.co.uk] Message-ID: To: Dmitry Stogov , internals Date: Fri, 22 Apr 2016 12:46:27 +0100 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2016 11:46:27.0654 (UTC) FILETIME=[9AC6F660:01D19C8C] Subject: RE: [PHP-DEV] [RFC] PHP Attributes From: tpunt@hotmail.co.uk (Thomas Punt) Hi Dmitry!=0A= =0A= > Hi=2C=0A= >=0A= >=0A= > I would like to present an RFC proposing support for native annotation.= =0A= >=0A= > The naming=2C syntax and behavior are mostly influenced by HHVM Hack=2C b= ut not exactly the same.=0A= >=0A= > The most interesting difference is an ability to use arbitrary PHP expres= sions as attribute values.=0A= >=0A= > These expressions are not evaluated=2C but stored as Abstract Syntax Tree= s=2C and later may be accessed (node by node) in PHP extensions=2C preproce= ssors and PHP scripts their selves. I think this ability may be useful for = "Design By Contract"=2C other formal verification systems=2C Aspect Oriente= d Programming=2C etc=0A= >=0A= >=0A= > https://wiki.php.net/rfc/attributes=0A= >=0A= >=0A= > Note that this approach is going to be native=2C in contrast to doc-comme= nt approach that uses not well defined syntax=2C and even not parsed by PHP= itself.=0A= >=0A= >=0A= > Additional ideas=2C endorsement and criticism are welcome.=0A= =0A= Just a couple of comments on this:=0A= =0A= 1. I'd definitely reuse the php-ast extension for parsing the code into an= =0A= AST. It performs a number of transformations on PHP's underlying AST=0A= that make it much nicer to use (namely better consistency). It is also=0A= less fragile by having the abstraction between PHP's internal AST and=0A= the AST that is exposed to userland (enabling for internal AST changes=0A= without=A0impacting the AST exposed to userland).=0A= =0A= 2. You mentioned about moving some of the php-ast extension into core.=0A= I wonder if it would be better to just move the whole extension into the=0A= core first=2C=A0and then enable this functionality if the php-ast=A0extensi= on=A0is=0A= enabled.=0A= =0A= Also=2C slightly tangential=2C but the RFC says attributes are supported on= =0A= class constants=2C yet=A0doc comments (IIRC) are not. I wonder if support= =0A= for doc comments=A0should be added for class constants?=0A= =0A= Thanks=2C=0A= Tom =