Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92625 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44400 invoked from network); 22 Apr 2016 01:06:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Apr 2016 01:06:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=guilhermeblanco@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=guilhermeblanco@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.177 as permitted sender) X-PHP-List-Original-Sender: guilhermeblanco@gmail.com X-Host-Fingerprint: 209.85.213.177 mail-ig0-f177.google.com Received: from [209.85.213.177] ([209.85.213.177:37875] helo=mail-ig0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/8C-14036-A0979175 for ; Thu, 21 Apr 2016 21:06:18 -0400 Received: by mail-ig0-f177.google.com with SMTP id g8so2804052igr.0 for ; Thu, 21 Apr 2016 18:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c7tNE2TbNSKJVfRdZ2D6nlfiTTMqS9DRKFplHa8vj4o=; b=I4pPx4mH+B+E4gV22J+zOU38vaEo4EhOUovt6Y2AtuXvp6ZXxjbEu5nDmIvkVtKspn 1W5ImH32DMn9EyKzerZcPR2T8xdcU6TpbOrNd/WGyTi49pW7r0GA8h4iB+S2ruqe3r9M qqwZtnGQho7UFhEbBsvEK38DZ9tl+d2OsZPdkAChe3Tx869rVDvfzZfh+iWKRD+kxnbH D0JMgYy4NYRiPAOavZIetom7af1gYrxLFf5k0mR28hwxcV/sagv+7MvezBRMg8LL6fN+ eDXmnU06FdFpY+HrnHaYmQfdnUWrd9DPbZ/faLr+8YpsztQmC6Am1Wx4cPnHRjwbthep RwQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c7tNE2TbNSKJVfRdZ2D6nlfiTTMqS9DRKFplHa8vj4o=; b=DfeD8jglJuA9mRF9uER0CxKveKd4RhQhfJW5tX9CvVWE2defGeIhRRCj2xwlfLg7Ma 2EfkpSOVxRnwboegXNKcH8NjlxrwIWvdzRbS2ImxDie6ALbVC7tq9zn5DSZdL1iD9JOZ C/x2BggoIkTp3iFKkeuFb9IJSCLfBpTKLCo15hdwoJr7XEHy1TxlwNnIdgjXGqi58BU7 O90l7osgKba68PnGLRsj7iqVjD0K87TTqAzlpnLGlnE4cTrXXG2/pQyDEJegFYfoa+Od ssyltVPDtf8eJuww87euHpYDtCBhhhP49fDu8YSbwYWuAU81+6+e7xC8ZjZEshcvxgud /RsQ== X-Gm-Message-State: AOPr4FWDNTDG4zN2+JwE0vHREQeJS3AigAwuaJNSfRd/ip2NdAHRCwzhLYFd1HyNQyDedKc5jFYlkW0POrGcUQ== X-Received: by 10.50.123.132 with SMTP id ma4mr1070782igb.92.1461287175868; Thu, 21 Apr 2016 18:06:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.85.10 with HTTP; Thu, 21 Apr 2016 18:05:56 -0700 (PDT) In-Reply-To: <571965D1.9020102@zend.com> References: <571965D1.9020102@zend.com> Date: Thu, 21 Apr 2016 21:05:56 -0400 Message-ID: To: Dmitry Stogov Cc: Dominic Grostate , PHP internals Content-Type: multipart/alternative; boundary=001a113603be0859620531086f31 Subject: Re: [PHP-DEV] [RFC] PHP Attributes From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com") --001a113603be0859620531086f31 Content-Type: text/plain; charset=UTF-8 Hi Dmitry, As a previous suggester of metadata information built-in into PHP, and also one of developers of the most used metadata library written in PHP, I understand this feature implementation requires several design decisions and also a good understanding of specific situations users may require. While I am a strong supporter of a more robust solution, this is already a good start. A few things I'd like to ask for my own understanding and also suggestions too: 1- I understand you took a minimalistic approach towards a "dumb" implementation for attributes (when I mean "dumb", the idea here is towards a non-OO approach). Can you explain your motivations towards this approach? I see two distinct approaches of implementation for this feature. Both of them have some common demands, like lazy initialization of metadata. Here they are: - Simplistic approach, which lets consumers of the feature do all the work related to validation, assertion of valid keys, values, etc This does not invalidate the ability to leverage of some features that a more robust implementation demands. - Robust approach: language takes the burden of instantiating complex structures, validating, assertion of valid keys, values, if this complex structure is allowed to be instantiated in that given class, method, etc. 1- Your approach is basically defining an array. Could you explain your line of thinking on why you didn't consider a syntax like the one below? <["key" => "value"]> class Foo {} 2- I see that you added support over functions, classes, constants and properties. According to the RFC, getAttributes() was added over ReflectionFunction. Is there a reason why support was not added to methods (ReflectionMethod extends ReflectionFunctionAbstract, which was not mentioned on RFC)? Any reason to not support it in function/method parameters? 3- Did you put any thought on inheritance? What I mentioned in comment #1 is even smaller than what you implemented in RFC. Assuming you keep the RFC approach, did you consider support overrides, inherit, etc? 4- I understand that a more robust attribute solution would be required to achieve this, but one of the biggest advantages of AOP is the ability to perform custom logic before, after or around... However, I don't know if any kind of triggers came in your head or are planned as a future RFC. Let me highlight one example: Every time a class, property or method is called that is annotated as <>, I would like to issue an E_USER_DEPRECATED warning. A trigger-like solution would be required. Did this concept came to your mind? Regards, On Thu, Apr 21, 2016 at 7:44 PM, Dmitry Stogov wrote: > > > On 04/22/2016 02:16 AM, Dominic Grostate wrote: > >> >> This is amazing. It would actually allow us to implement our automated >> assertions ourselves, as opposed to requiring it within the language. >> >> this was the idea - to give a good tool instead of implementing every > possible use-case in the language. > > Could it also support references? >> >> <> >> function foo($a) { >> >> } >> >> yes. "&$a" is a valid PHP expression. > > If you plan to use this, I would appreciate, if you to build the patched > PHP and try it. > The early we find problems the better feature we will get at the end. > > Thanks. Dmitry. > > > On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" > dmitry@zend.com>> wrote: >> >> Hi, >> >> >> I would like to present an RFC proposing support for native >> annotation. >> >> The naming, syntax and behavior are mostly influenced by HHVM >> Hack, but not exactly the same. >> >> The most interesting difference is an ability to use arbitrary PHP >> expressions as attribute values. >> >> These expressions are not evaluated, but stored as Abstract Syntax >> Trees, and later may be accessed (node by node) in PHP extensions, >> preprocessors and PHP scripts their selves. I think this ability >> may be useful for "Design By Contract", other formal verification >> systems, Aspect Oriented Programming, etc >> >> >> https://wiki.php.net/rfc/attributes >> >> >> Note that this approach is going to be native, in contrast to >> doc-comment approach that uses not well defined syntax, and even >> not parsed by PHP itself. >> >> >> Additional ideas, endorsement and criticism are welcome. >> >> >> Thanks. Dmitry. >> >> > -- Guilherme Blanco Lead Architect at E-Block --001a113603be0859620531086f31--