Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92629
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.123 as permitted sender)
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAFKaYMqg6H2YAgS-ATjcYtXw8GLbp_Kr+VuZFMRPZTkAS1g0hA@mail.gmail.com>
 <571965D1.9020102@zend.com>
 <CAFp73Xs=-sK4ZM-mM8Jp5wWkpYLuen+-K0R9xfZaumBM_sPPFw@mail.gmail.com>
CC: Dominic Grostate <codekestrel@googlemail.com>, PHP internals
	<internals@lists.php.net>
Message-ID: <5719CDB2.90103@zend.com>
Date: Fri, 22 Apr 2016 10:07:30 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAFp73Xs=-sK4ZM-mM8Jp5wWkpYLuen+-K0R9xfZaumBM_sPPFw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------010507030504030501080304"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2016 07:07:42.7664 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1787
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)

--------------010507030504030501080304
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit



On 04/22/2016 04:05 AM, guilhermeblanco@gmail.com wrote:
> 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.

I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization during 
compilation - this is just not possible from implementation point of view.
Now attributes may be stored in opcache SHM and relive request boundary.
Objects can't relive requests.
>
> 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 {}
I didn't try to invite new syntax. Just completely took it from HHVM.

>
> 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?
ReflectionMethod is a child of ReflectinFunction, so it's supported.
Attributes are allowed for the same entities as doc-comments (they are 
not allowed for 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?

In my opinion, attributes don't have to be inherited.
If you think differently - please explain your point.
>
> 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 <<deprecated>>, I would like to issue 
> an E_USER_DEPRECATED warning. A trigger-like solution would be 
> required. Did this concept came to your mind?
This is not a subject of this RFC.
Attributes provides a storage for metadata, but don't define how to use 
them.
Especially, for your use-case:
1) it's possible to create preprocessor that embeds corresponding 
trigger_error() call
2) it's possible to write a PHP extension that plugs-into compiler chain 
and checks <<deprecated>> attribute for each compiles function, then 
sets ZEND_ACC_DEPRECATED flag
3) It's also possible to override DO_FCALL opcodes and perform checks 
there (this is inefficient)

Thanks. Dmitry.

>
>
>
> Regards,
>
> On Thu, Apr 21, 2016 at 7:44 PM, Dmitry Stogov <dmitry@zend.com 
> <mailto:dmitry@zend.com>> 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?
>
>         <<sanitize(&$a)>>
>         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
>         <mailto:dmitry@zend.com> <mailto:dmitry@zend.com
>         <mailto: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


--------------010507030504030501080304--