Re: [RFC] PHP Attributes
| From: | Dmitry Stogov | Date: | Mon, 25 Apr 2016 09:00:06 +0000 |
| Subject: | Re: [RFC] PHP Attributes | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-92718@lists.php.net to get a copy of this message | ||
On 04/25/2016 06:23 AM, Stanislav Malyshev wrote:
Hi!I'm going to extend RFC with namespace support. Attribute name is going to be qualified string.https://wiki.php.net/rfc/attributesI've read the proposal and I like the idea of reviving the attributes idea and the simplicity of the approach. I have the following questions for it: - Namespacing. Since the attribute names are not processed in any way according to spec, it may be rather hard to ensure attribute requirements from different domains do not conflict, and we do not get into the same problem we've got into with class names before we implemented namespaces. How it is planned to address the issue?
- The expressions support is nice, however I'm not sure I understand what PHP application is supposed to do with syntax trees? I.e. taking the example in the RFC, if I got AST\Node representing <<test($a + $b > 0)>>, how do I use it? Would I implement mini-PHP-engine in PHP to evaluate such an expression? Am I supposed to use some other functionality to do it? It is unclear. I don't think promoting reimplementing PHP expressions in a myriad of different ways (which all would be subtly different and distinct from how PHP understands such expressions) is not good, and if we expose those trees we should also provide means to work with them. Otherwise any advanced usage of the feature would mean basically reimplementing PHP engine in PHP. AST is going to be processed and evaluated using php-ast extension.Nikita was going to propose including it into core distribution.
As a side note, my personal opinion is that for about 90% of use cases expressions are not needed. For 90% of those which are needed, string + some form of eval would cover it's use case since all the'd be doing is evaluating the expression and checking the resulting value.This is a question. We may use AST expression or just strings. In second case we miss syntax verification at compile time. I'm going to describe the problem in RFC and set an additional voting question.
- As far as I can see, AST extension has no documentation except for initial README. If it is going to end up in core, this needs to be fixed. Preferably before it is merged into core. - I would also consider moving AST namespace under \PHP since we have this one reserved (unlike \AST which we did not reserve). For me AST is the best choice here.
- Are attributes also allowed to apply to anonymous classes/functions? Would the syntax still work in that case?No. At least now.
_ I also think <<...>> syntax is ugly and @attribute syntax would be much better (and also is used in Java attributes and Python decorators). That's my personal opinion though.@ is reserved for silence operator. Thanks. Dmitry.
Thanks,