Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93114 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15977 invoked from network); 8 May 2016 15:54:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 May 2016 15:54:11 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:51722] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DC/61-04420-1216F275 for ; Sun, 08 May 2016 11:54:09 -0400 Received: from cable-81-173-133-15.netcologne.de ([81.173.133.15] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1azR1x-0003Zu-QG; Sun, 08 May 2016 15:54:06 +0000 Reply-To: internals@lists.php.net References: <5723F2AE.2020806@garfieldtech.com> <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com> <572B5781.4000403@garfieldtech.com> To: Dmitry Stogov , Jesse Schalken , Dan Ackroyd Cc: Larry Garfield , "internals@lists.php.net" Message-ID: Date: Sun, 8 May 2016 17:53:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O15gaLdKIb18iUH6xb6n5vicwIM7qR4De" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal From: php@fleshgrinder.com (Fleshgrinder) --O15gaLdKIb18iUH6xb6n5vicwIM7qR4De Content-Type: multipart/mixed; boundary="9Ni83JBCJApnxqbiiFWSCvWRQoPk5JFPW" From: Fleshgrinder Reply-To: internals@lists.php.net To: Dmitry Stogov , Jesse Schalken , Dan Ackroyd Cc: Larry Garfield , "internals@lists.php.net" Message-ID: Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal References: <5723F2AE.2020806@garfieldtech.com> <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com> <572B5781.4000403@garfieldtech.com> In-Reply-To: --9Ni83JBCJApnxqbiiFWSCvWRQoPk5JFPW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/6/2016 8:02 AM, Dmitry Stogov wrote: > On 05/06/2016 05:06 AM, Jesse Schalken wrote: >> If you're going to say "do what you want" with regards to annotations,= >> then >> just let them be a text string. Parsing the annotation as PHP but not >> evaluating it as PHP seems a very strange and arbitrary half-way >> point. If >> the thing consuming the AST is expected to eval() it, then why didn't = PHP >> do that already? If the thing consuming the AST is expected not to eva= l() >> it, then it must effectively implement it's own language sharing PHP's= >> syntax but not PHP's semantics. Since it can't possibly attach meaning= to >> all of PHP's syntax, PHP will enforce that the string is valid PHP eve= n >> though the annotation language will be a very small subset. Not only d= oes >> that buy you very little in terms of validity checking, but it constra= ins >> the annotation language to be a subset of PHP's syntax even when such = a >> constraint may be entirely inappropriate. >> >> A true "do what you want" approach, if that is the right approach, >> would be >> for the annotation body to be a free text string. >=20 > You talk about a subset of the proposed RFC. > It proposes an additional question about AST usage. >=20 I think he is talking exactly about the proposed RFC, it is completely arbitrary and will lead to much confusion and it is not anymore useful than the current PhpDoc approach that we have in userland. Having an attribute grammar [1] adds overhead to PHP while parsing our files and removes only the regular expression stuff that is currently implemented in the annotation systems of all the software out there; which is at least offline. I do not see a single benefit in the current feature proposal. Especially since one can already run the content of a PhpDoc tag through the AST thingy and *bam* you have exactly the same thing. What we need is an annotation system that works for userland and not this attribute grammar crutch just because it is easier to come up with and agree upon. [1] https://en.wikipedia.org/wiki/Attribute_grammar --=20 Richard "Fleshgrinder" Fussenegger --9Ni83JBCJApnxqbiiFWSCvWRQoPk5JFPW-- --O15gaLdKIb18iUH6xb6n5vicwIM7qR4De Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXL2EaAAoJEOKkKcqFPVVr5ZIP/RPBs7HirT5l97ZkwoBKiALv 9FhN6m7RU/ODut35Dj1pNntFfHlT8Uaf97PqlULdCWlJG0QQ07/L8U8h/XlVLt2S GHJNP+OulPDSUuzWV4YcPbqtkMUS4h3Y9y0+cLvYEYycOUAFQkarl3cIicuq47hc PUFSJC0lLyqejhhUYEXenmbZq24i8Jre81bsERlm5dsZWogGtRj45k3FyvWkSxkA gY07CloiQ1RV9x/ZBfwI+FjzSGt9xF6Mdj93rdQm6KIK9Mv1VxauVh7/uw4Wt5ET 2S+fLtGqNE3C/RLPSUF2Juh/+Z05Wae8Mtx6JNG9FGSpUpb424yH8neiPgfCe+Uu JZhQnsVocDrADoH8f/q7IIVz4lEPT38vDQAxZs1Oy+T7+jQcaLMhMpha1q0pAm25 Yb1EjJbti3rfa3zH4hEkdbcF/tFh+vrIlZJ5y83tlStQZqUg7Bmu6hJ77jIXwjOS M0llox48LYRzau7I80SRP5NJ/NDoMm59apwB6wRA17oiBVv8HVvzPr1NjQkkpkDs 0i52hF/w5nevbDrvzXpH1IwOxrhohEMfKvqjFTpat6CP2wNr1xLqO7zOSagQUpp5 4i+AAYyCvCI1P3vV7uXS1SByyX1g6GZyMdmrQi31iZI0ZJuofUVlMoHrvYUCHP0b 3y2sJSeTxqpZHsQTCFBF =5gST -----END PGP SIGNATURE----- --O15gaLdKIb18iUH6xb6n5vicwIM7qR4De--