outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

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 <dmitry@zend.com <mailto:dmitry@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 <dmitry@zend.com
    <mailto:dmitry@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
        <dmitry@zend.com <mailto:dmitry@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 <pthreads@pthreads.org
            <mailto:pthreads@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.larsson@telia.com
            <mailto:bjorn.x.larsson@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