On 05/11/2016 11:42 AM, Joe Watkins wrote:
Dmitry,
> Except the fact, that doc-comment content don't have to conform to
any rules
Nor does an attributes value that is just a string, that isn't
validated by compiler ... it doesn't *have* to conform to any rules.
That's exactly what people are voting for though, that seems to be
what people want
I think, different people expect very different functionality and many
just don't like to introduce replacement for existing doc-comments.
Probably the majority of voters against AST, just don't care about
applications of this feature (extensible compiler, meta-programming,
compile-time execution, etc)
I desperately do not want that. I don't see the remarkable difference
(although there is obviously difference) between attributes that are
just strings or constant values and doc comments.
The difference is small, but attributes standardize syntax and provide
standard storage with simple API.
In my view, better to get at least this than nothing.
> and you have to parse it and extract the necessary part of meta
information every time you need it.
You know that's not really true, there are already hooks and
mechanisms to "compile" strings in doc comments, I used them literally
yesterday ...
I don't know about such hooks in the engine. do I miss something? :)
I used them in anticipation that we would get a superior solution some
time soon ... it now looks like we will not :(
I missed. do you speak about attributes with AST or doc-comments with
strings.
I don't want to invent ways to parse code, or extract it from anywhere
... we have a whole engine, an entire folder of code dedicated to
that, it is nonsensical not to utilize it.
You shouldn't worry about parsing PHP grammar in attribute strings, we
would just provide an API call in the engine that reuses zendparse() and
returns AST.
This would take just 10-20 C lines.
Thanks. Dmitry.
Cheers
Joe
On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:
On 05/11/2016 09:57 AM, Joe Watkins wrote:
Dmitry,
> but it's possible to get the same power translating string
values of attributes into AST in the hooks.
Aware.
Enough of the complexity is already the responsibility of the
consumer of the attributes.
It's already possible to get strings (and so AST) from doc
comments, we don't need anything new if that's all you want to do.
Essentially, moving something from doc comments to <<here>> makes
zero sense to me.
Except the fact, that doc-comment content don't have to conform to
any rules, and you have to parse it and extract the necessary part
of meta information every time you need it. It's not a big problem
to do this using Doctrine library, but how are you going to do
this in a compiler hook?
Cheers
Joe
On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:
On 05/11/2016 09:02 AM, Joe Watkins wrote:
Morning Dmitry,
> On the other hand simple string may be parsed into AST
with just one additional call to ast\compile_string().
You're not really suggesting that I write my tools in user
land, are you ? It's me, Joe :)ce
At first days of RFC discussion Sara pointed on over-design
regarding AST.
I saw sense in here comments and updated RFC.
I *only* want attributes as they were originally proposed,
and I can't vote to reflect that.
As discussed in private, what I want is attributes, as
originally proposed, and a hookable compiler; Anything else
is not good enough.
Personally, I'm for AST as well, but it's possible to get the
same power translating string values of attributes into AST
in the hooks.
Thanks. Dmitry.
Cheers
Joe
On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov
<dmi...@zend.com <mailto:dmi...@zend.com>> wrote:
Hi Joe,
The sense in native support for AST is questionable.
On one hand this allows syntax verification.
On the other hand simple string may be parsed into AST
with just one additional call to ast\compile_string().
Thanks. Dmitry.
------------------------------------------------------------------------
*From:* Joe Watkins <pthre...@pthreads.org
<mailto:pthre...@pthreads.org>>
*Sent:* Wednesday, May 11, 2016 7:46:09 AM
*To:* Björn Larsson
*Cc:* Dmitry Stogov; PHP internals
*Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
Morning Dmitry,
I'm not really happy with the voting options here.
I would not vote in favour of a patch that does not
include support for AST, that's a completely different
feature.
As it is, I have to vote yes in favour of AST, but
it may be counted as a vote in favour of attributes
without AST ...
This doesn't seem right ... I don't want attributes
without AST, and there is no voting option to reflect that.
Cheers
Joe
On Tue, May 10, 2016 at 11:09 PM, Björn Larsson
<bjorn.x.lars...@telia.com
<mailto:bjorn.x.lars...@telia.com>> wrote:
Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
On 05/11/2016 12:29 AM, Björn Larsson wrote:
Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:
Hi internals,
I've started voting on "PHP Attributes" RFC.
https://wiki.php.net/rfc/attributes
In my opinion, "PHP Attributes" might be
a smart tool for PHP extension, but it's
not going to be the end of the world, if
we decided to live with doc-comments only.
Thanks. Dmitry.
Thanks for the good work. Regarding naming,
I googled
"PHP attributes" vs "PHP annotations" and
looking at the
result, my view is that that Annotation is a
better naming
then Attributes. Any hope in changing it?
The more I listen to arguments of adepts of
existing PHP annotation systems, the more I
think, that "PHP attributes" is the right name
for this proposal.
This feature is not just for PHP annotation systems.
Thats a fair point, so Annotation it's not. Still,
when I hear PHP
attributes I associate it with class / function
attributes. Maybe
just a question getting used to the naming. Hm,
wonder if PHP
directives could have been an option?
Regards //Björn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
<http://www.php.net/unsub.php>http://www.php.net/unsub.php
