Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92684 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 855 invoked from network); 24 Apr 2016 11:56:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Apr 2016 11:56:12 -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 212.232.25.162 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.25.162 mx206.easyname.com Received: from [212.232.25.162] ([212.232.25.162:52520] helo=mx206.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BD/52-21220-A54BC175 for ; Sun, 24 Apr 2016 07:56:11 -0400 Received: from cable-81-173-133-226.netcologne.de ([81.173.133.226] 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 1auIdu-0001M3-Qa; Sun, 24 Apr 2016 11:56:04 +0000 Reply-To: internals@lists.php.net References: <571BA0F0.2030400@fleshgrinder.com> <571C82A7.2060706@fleshgrinder.com> To: Benjamin Eberlei , PHP Internals Cc: Sara Golemon , "dmitry@zend.com >> Dmitry Stogov" Message-ID: <571CB44C.1000704@fleshgrinder.com> Date: Sun, 24 Apr 2016 13:55:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aEunjbJPGMANn12dJ5Pm0l2j49etI1XBe" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC] PHP Attributes From: php@fleshgrinder.com (Fleshgrinder) --aEunjbJPGMANn12dJ5Pm0l2j49etI1XBe Content-Type: multipart/mixed; boundary="PFGGfe2AVIb3vdNQ43sbjvNX0WUPpqha9" From: Fleshgrinder Reply-To: internals@lists.php.net To: Benjamin Eberlei , PHP Internals Cc: Sara Golemon , "dmitry@zend.com >> Dmitry Stogov" Message-ID: <571CB44C.1000704@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC] PHP Attributes References: <571BA0F0.2030400@fleshgrinder.com> <571C82A7.2060706@fleshgrinder.com> In-Reply-To: --PFGGfe2AVIb3vdNQ43sbjvNX0WUPpqha9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder w= rote: >=20 >> The invariant could also be added as an additional branch to the class= >> instead of a method, since it would not work like a method. >> >> class A {} invariant {} >> >> function f() {} require {} ensure {} >> >> This would also align nicely with closures and anonymous classes, whic= h >> is kind a problematic with annotations. >> >=20 > You are way off topic with this imho. >=20 No, not at all! The RFC explicitly mentions design by contract (DbC) and that is why I am responding to that. I do not think that annotations should or could be used for DbC and want to raise this issue here. Of course all of the above is a completely different story and requires its own RFC as well as implementation. However, DbC should not be used to justify the addition of annotations to PHP. (If libraries choose to use it for that, different story.) On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > Attributes as proposed by Dimitry are not executing functions, they are= > only metadata > that can be retrieved through reflection API. I think a python style > decorator approach > that you propose here, executing functions is not what the different > pro-annotations, > pro-attributes or pro-DesignByContract fractions want/need. >=20 > You are proposing something along the lines of AOP, which is an entirel= y > different beast > in my opinion. >=20 I know and that is why I am writing that the usage of brackets is not a good idea because it suggests exactly that. We need to think about a possible feature as outlined by myself (reactive annotations or /Python style decorator approach/ as you call it) in order to not implement annotations in a way that would kill exactly such a feature in a possible future. Hence, I am not off topic because I am thinking outside of the box in the context of the whole ecosystem. Something that I see not happening in this RFC nor its discussion. --=20 Richard "Fleshgrinder" Fussenegger --PFGGfe2AVIb3vdNQ43sbjvNX0WUPpqha9-- --aEunjbJPGMANn12dJ5Pm0l2j49etI1XBe 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 iQIcBAEBCAAGBQJXHLRQAAoJEOKkKcqFPVVr+fwQALp9jYOKhj3LN4uYUIQNLi+7 r5tqGe3jWOxlZb3W3SQ+SrswR5SPGYhYYW6zIXalJnxZZoS0iv5SR8U+t3M3xE0j eP4OaAVBn+m5vYjnOvqWSf+OgHktwxZ6NTYH05ELv6g8wdLqOsqE/ZVh1AJNXdSv WZrSI4bwkFbZfzv+cAbyakuIYB37OuUaUKJbkhQ+8wvy8aewqMDf9a2B0rdJylc7 D51qthYgiq+DRJ2wfwOzvwP5hKX8isknSz/WPbubQQ6675o6Yo54x7If6w06SYFi RN5ifHjqQosoT4eQnrUOiTYNaRa9nc4+q+ZYQPnFBMM8+GRZmYIrcUSmNu9t8f/v rzgtLMlZKcHtz0JWey+Xq+S3FNRTV6sJ9hK7e2E1MeQp0HmwV6HCfr1nJtrhaKwm lQlwrBInKfyxK3FFx7TxebCOEadtwbxdcL7CPsNXp6k3Ie4KldZKn8rvLsLU/bLs RfI/m6q7BRNp+qNzmFqgh+HU2jcs42r9u/2v9ei3mqJD6200LoTTWstYs5Og/bTs fm4GZj9FmMjoo32xs2BZkQcp0cMV33nVMED5FW9xYpmz1zN1W28MmWewviKWEb0n smDWryW9aaDmnLxkBLaQjFfOPzoUj2tIGVOywqp/zgLRvyio1pOOT6wxUuwP/IQl DujQqN1u+zflXKFEQuKS =F3SI -----END PGP SIGNATURE----- --aEunjbJPGMANn12dJ5Pm0l2j49etI1XBe--