FAQ
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.

Search Discussions

  • Fleshgrinder at May 10, 2016 at 6:35 pm

    On 5/10/2016 8:29 PM, Dmitry Stogov wrote:
    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.
    I hope it's going to be negative. The name is misleading and the AST
    approach is not really useful in userland. :(

    --
    Richard "Fleshgrinder" Fussenegger
  • Rasmus Schultz at May 10, 2016 at 8:07 pm
    A couple of quick comments - I'm sorry, I haven't had time to get them
    in before now.

    In my opinion, this is pretty bad, for one primary reason: these are
    just names and values.

    The advantage of this over parsing doc-blocks at run-time is pretty
    limited - you can basically only guarantee syntax, you can't guarantee
    anything about annotation types or the required arguments. Names and
    values still need to be resolved at run-time - that seems really
    brittle and redundant.

    It's also not what the community wants - they want classes, e.g.
    Doctrine annotations, the most popular choice:

    https://github.com/doctrine/annotations

    Or the project that I started (but no longer contribute to)

    https://github.com/php-annotations/php-annotations/

    We want classes for the same reason we don't want arrays with magical
    key/value pairs - for example, so we can have static analysis,
    inspections, auto-completion in IDEs, etc.

    Annotations need more consideration for design time - run time
    attributes, in my opinion, is not enough, and brings more net
    complexity than actual annotations.

    Because no behavior or coupling is defined, they won't behave well,
    and the coupling will be unpredictable - we'll have lots of
    frameworks, all doing things differently, which is the same situation
    we have now.

    In my opinion, if we need this functionality at all, we need real
    annotations - not just new syntax for the data, but taking into
    account the behavior.

    I think annotations could be as simple as this:

    https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

    In my opinion, this immediately solves a lot more problems with a lot
    less effort (and fragmentation!) in userland.

    It's immediately useful in any script, without having to select and
    install a third-party Composer package or write complex code to
    interpret the data.

    As for "softer" and more complex rules, e.g. regarding the number of
    allowed annotations of the same type, or the type of element they're
    allowed on, etc. - it doesn't make much sense to try to implement or
    enforce such rules, as these wouldn't be enforced until the moment you
    actually query the annotations of an element anyhow. This could be
    either left up to userland, e.g. consumers can easily check and
    enforce constraints themselves using conditionals and exceptions.

    As for single vs multiple annotations of the same type, I would ignore
    this as well, for the same reason - even if you had an API like
    getSingleAnnotation($type) this would have to return either an
    instance of $type, or null, so the consumer is still left with the
    burden of having to check the result, e.g. no more or less of a burden
    than checking the number of returned annotations with count().

    To summarize:

    - Annotations are immediately useful in any script
    - Annotations are coupled directly to classes
    - Classes is what most of us want in the end
    - Static type-checking is possible

    I think that attributes are not the way to go about this - it's not
    substantially better than the status quo and doesn't lead to anything
    immediately useful to most developers without also
    adopting/writing/learning a suitable framework.

    Just my opinions.

    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:
    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.
  • Benjamin Eberlei at May 10, 2016 at 8:48 pm

    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    one question, Rasmus Schultz post goes into the similar direction.

    Any reason why the annotations are only a numeric list and not key value
    pairs? Key-Value would be much more powerful and address a ton of
    objections for us (Doctrine).

    In the current state it is pretty limited for more complex use-cases. I
    don't want to fully embrace the complexities that Larry showed for Drupal
    (in my opinion, too much annotations), but without key value pairs we could
    only use this when we nested JSON into the attribute value strings for
    example, not something I want to mix.

    Thanks. Dmitry.
  • Dmitry Stogov at May 10, 2016 at 9:03 pm

    On 05/10/2016 11:48 PM, Benjamin Eberlei wrote:

    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.


    one question, Rasmus Schultz post goes into the similar direction.

    Any reason why the annotations are only a numeric list and not key
    value pairs? Key-Value would be much more powerful and address a ton
    of objections for us (Doctrine).
    Attributes their selves are key-values, only nested values are numeric,
    but instead of simple values it's possible to use expression AST, that
    is more powerful than key-values.
    In the current state it is pretty limited for more complex use-cases.
    I don't want to fully embrace the complexities that Larry showed for
    Drupal (in my opinion, too much annotations), but without key value
    pairs we could only use this when we nested JSON into the attribute
    value strings for example, not something I want to mix.
    The Drupal example implementation on top of attributes is included in RFC.

    Thanks. Dmitry.
  • Larry Garfield at May 16, 2016 at 1:49 am

    On 05/10/2016 03:48 PM, Benjamin Eberlei wrote:
    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    one question, Rasmus Schultz post goes into the similar direction.

    Any reason why the annotations are only a numeric list and not key value
    pairs? Key-Value would be much more powerful and address a ton of
    objections for us (Doctrine).

    In the current state it is pretty limited for more complex use-cases. I
    don't want to fully embrace the complexities that Larry showed for Drupal
    (in my opinion, too much annotations), but without key value pairs we could
    only use this when we nested JSON into the attribute value strings for
    example, not something I want to mix.
    I fully agree that Drupal's annotation use goes over-board at present.
    :-) I used it as a real-world stress-case. However, even if we were to
    scale back in Drupal the current Attributes proposal is too low-level to
    be useful.

    I do not have voting karma, but I would endorse voting NO on this RFC as is.

    --Larry Garfield
  • Björn Larsson at May 10, 2016 at 9:29 pm

    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?

    Regards //Björn Larsson
  • Dmitry Stogov at May 10, 2016 at 10:00 pm

    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.

    Regards //Björn Larsson
  • Björn Larsson at May 10, 2016 at 10:09 pm
    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
  • Joe Watkins at May 11, 2016 at 4:46 am
    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 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
  • Dmitry Stogov at May 11, 2016 at 5:26 am
    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>
    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 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
  • Joe Watkins at May 11, 2016 at 6:02 am
    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 :)

    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.

    Cheers
    Joe


    On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov 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>
    *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
    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
  • Joe Watkins at May 11, 2016 at 6:10 am
    Morning,

         Because you have confused the vote by adding additional options very
    late in the discussion, and because the majority are in favour of something
    I think is harmful; I've had to vote no, on a feature that I want :s

    Cheers
    Joe
    On Wed, May 11, 2016 at 7: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 :)

    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.

    Cheers
    Joe


    On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov 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>
    *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> 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
  • Dmitry Stogov at May 11, 2016 at 6:45 am

    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 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
    *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
    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>

  • Joe Watkins at May 11, 2016 at 6:57 am
    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.

    Cheers
    Joe
    On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov 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 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>
    *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> 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
  • Dmitry Stogov at May 11, 2016 at 7:11 am

    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 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
    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
    *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
    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

  • Joe Watkins at May 11, 2016 at 8:42 am
    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 :s

    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.
    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 used them in anticipation that we would get a superior solution some time
    soon ... it now looks like we will not :(

    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.

    Cheers
    Joe


    On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov 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 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>
    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>
    *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>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>
    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>http://www.php.net/unsub.php
  • Benjamin Eberlei at May 11, 2016 at 9:02 am

    On Wed, May 11, 2016 at 10: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 :s

    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.
    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 used them in anticipation that we would get a superior solution some time
    soon ... it now looks like we will not :(

    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.
    Yes agree. I have to admit not to have read the RFC with my full attention
    before, i would have spotted this otherwise.
    I would really love to have attributes being arbitrarily nested arrays in
    addition to just a list of strings and have the PHP parser
    recognize, parse and validate that its correct.

    <<ORM\Entity("User")>>
    getAttributes() returns ["ORM\Entity" => "User"]

    ^ This is a very simple example from the RFC, but next to the very complex
    Drupal example, there are rather "lightweight"
    usages that make up the majority of Annotations in Docblocks right now. I
    would like to see:

    <<ORM\Entity("repositoryClass" => "MyApp\UserRepository", "table" =>
    "users")>>
    getAttributes() returns ["ORM\Entity" => ["repositoryClass" =>
    "MyApp\UserRepository", "table" => "users"]]

    The example from Drupal parsing the AST Nodes in the RFC nodes is extremely
    complex code and would lead again to hundrets of slightly different
    implementations
    and no standardization around them. Essentially re-implementing the PHP
    Parser in PHP on top of ast\nodes is not really what 80% of the users need
    here, which is
    arbitrary metadata (east way to represented in PHP as array).

    Cheers
    Joe


    On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov 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 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>
    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>
    *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>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>
    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>http://www.php.net/unsub.php
  • Dmitry Stogov at May 11, 2016 at 9:09 am

    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 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
    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
    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
    *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
    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

  • Joe Watkins at May 11, 2016 at 9:37 am
    Dmitry,
    The difference is small, but attributes standardize syntax and provide
    standard storage with simple API.

    It's too small. If we go ahead now and introduce constants or strings as
    the only supported form of attribute, we will never get anything more than
    that.
    I don't know about such hooks in the engine. do I miss something? :)
    There's no zend_set_magic_comments hook :D

    There's mechanisms like op array ctor, reserved space, and overloading all
    kinds of ways ... it's doable ... you already know it is ...
    I missed. do you speak about attributes with AST or doc-comments with
    strings.

    I'm saying I decided the write some extension code that "parses" doc
    comments, in anticipation that we would eventually get ast attributes ...

    Cheers
    Joe
    On Wed, May 11, 2016 at 10:09 AM, Dmitry Stogov wrote:



    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 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>
    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>
    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>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>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>
    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>http://www.php.net/unsub.php
  • Stanislav Malyshev at May 11, 2016 at 7:27 am
    Hi!
    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.
    Extending this, it's also possible to get the same power just extracting
    phpdocs and applying AST to them.
    --
    Stas Malyshev
    smalyshev@gmail.com
  • Dmitry Stogov at May 11, 2016 at 7:51 am

    On 05/11/2016 10:27 AM, Stanislav Malyshev wrote:
    Hi!
    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.
    Extending this, it's also possible to get the same power just extracting
    phpdocs and applying AST to them.
    In general yes, but we don't have grammar for doc-comments, and even
    extracting general string value may be not trivial.

    /**
       * Adds two positive numbers
       *
       * @ensures $x + $y >=
       * 0
       * // support for multi-line attribute values?
       * @on_enter @enter_function(__FUNCTION__);
       * '@' sign before enter_function() is a silence operator.
       */
    function add($x, $y) {
          return $x + $y;
    }
  • Rowan Collins at May 11, 2016 at 9:40 am

    On 11/05/2016 05:46, Joe Watkins wrote:
    I would not vote in favour of a patch that does not include support for
    AST, that's a completely different feature.
    Arguably, with the right choice of extension methods, an implementation
    requiring a single scalar could be extended to support arbitrary
    expressions later, since "scalar" is a subset of "expression".

    For instance, getAttributes() could provide a NULL value for any
    attribute with a non-scalar argument, and a separate getAttributesAST()
    could return an AST tree even if it consisted of a single constant.

    I'm still not convinced the freedom of AST is justified though, as
    opposed to a constant expression parsed according to standard PHP
    semantics (e.g. an associative array) or some specific syntax
    (effectively named parameters).

    I'd personally be against both options in the current RFC, because I
    think the language should be providing much more to make this useful.

    Regards,
    --
    Rowan Collins
    [IMSoP]
  • Benjamin Eberlei at May 12, 2016 at 2:29 pm

    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    I voted -1

    Reasons: from a Doctrine Annotations maintainer perspective, either getting
    a list (without keys) of strings back or ast\nodes are not enough or way
    too advanced for our use-case. The middle ground is missing where a
    <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
    nested array, that means getAttributes() does should not only return
    "string" or ast\node as result for each attribute, to there should be a way
    to get arrays back.

    Example:

    https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

    greetings
    Benjamin
  • Marco Pivetta at May 12, 2016 at 2:54 pm

    On 12 May 2016 at 16:29, Benjamin Eberlei wrote:
    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    I voted -1

    Reasons: from a Doctrine Annotations maintainer perspective, either getting
    a list (without keys) of strings back or ast\nodes are not enough or way
    too advanced for our use-case. The middle ground is missing where a
    <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
    nested array, that means getAttributes() does should not only return
    "string" or ast\node as result for each attribute, to there should be a way
    to get arrays back.

    Example:

    https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

    greetings
    Benjamin
    Urgh, that is indeed quirky, and makes it unusable.

    Is that an implementation or a spec issue? I know PHP 5.6+ allows array
    constants, but I am not aware of whether that is in the specification.

    Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for a
    version that either explicitly contains any constant expression or just
    supports arrays as constants.

    I'll also need to compile the branch and try it out myself before voting
    further: my bad for being hasty.

    Marco Pivetta

    http://twitter.com/Ocramius

    http://ocramius.github.com/
  • Rasmus Schultz at May 12, 2016 at 7:02 pm
    My problem with this PSR is you've created something that strongly
    resembles function or constructor calls, but in reality is just
    key/value pairs.

    That's confusing in itself, but also puts an unnecessary burden on
    consumers who have to figure out how to map this apparently
    "something" to "something real" - since it really isn't anything other
    than pretty syntax for arrays associated with source-code elements.

    Did anybody look at my notes here?

    https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

    I think this is much simpler and far more flexible - it lets you do
    what you're proposing with attributes (by annotating with simple
    arrays) and also lets you create annotation classes.

    Would anyone care to comment?

    On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta wrote:
    On 12 May 2016 at 16:29, Benjamin Eberlei wrote:
    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    I voted -1

    Reasons: from a Doctrine Annotations maintainer perspective, either getting
    a list (without keys) of strings back or ast\nodes are not enough or way
    too advanced for our use-case. The middle ground is missing where a
    <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
    nested array, that means getAttributes() does should not only return
    "string" or ast\node as result for each attribute, to there should be a way
    to get arrays back.

    Example:

    https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

    greetings
    Benjamin
    Urgh, that is indeed quirky, and makes it unusable.

    Is that an implementation or a spec issue? I know PHP 5.6+ allows array
    constants, but I am not aware of whether that is in the specification.

    Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for a
    version that either explicitly contains any constant expression or just
    supports arrays as constants.

    I'll also need to compile the branch and try it out myself before voting
    further: my bad for being hasty.

    Marco Pivetta

    http://twitter.com/Ocramius

    http://ocramius.github.com/
  • Benjamin Eberlei at May 12, 2016 at 7:27 pm

    On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz wrote:

    My problem with this PSR is you've created something that strongly
    resembles function or constructor calls, but in reality is just
    key/value pairs.
    Its actually function calls, not constructors calls :-)
    That's confusing in itself, but also puts an unnecessary burden on
    consumers who have to figure out how to map this apparently
    "something" to "something real" - since it really isn't anything other
    than pretty syntax for arrays associated with source-code elements.

    Did anybody look at my notes here?

    https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

    I think this is much simpler and far more flexible - it lets you do
    what you're proposing with attributes (by annotating with simple
    arrays) and also lets you create annotation classes.

    Would anyone care to comment?
    What happens if you say <<$x>> and then call $reflection->getAttributes()
    in your eample? what is $x?

    That is the problem with immediately evaluating everything non "constant".
    There is no context.
    On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta wrote:
    On 12 May 2016 at 16:29, Benjamin Eberlei wrote:
    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    I voted -1

    Reasons: from a Doctrine Annotations maintainer perspective, either
    getting
    a list (without keys) of strings back or ast\nodes are not enough or way
    too advanced for our use-case. The middle ground is missing where a
    <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
    nested array, that means getAttributes() does should not only return
    "string" or ast\node as result for each attribute, to there should be a
    way
    to get arrays back.

    Example:

    https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

    greetings
    Benjamin
    Urgh, that is indeed quirky, and makes it unusable.

    Is that an implementation or a spec issue? I know PHP 5.6+ allows array
    constants, but I am not aware of whether that is in the specification.

    Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for a
    version that either explicitly contains any constant expression or just
    supports arrays as constants.

    I'll also need to compile the branch and try it out myself before voting
    further: my bad for being hasty.

    Marco Pivetta

    http://twitter.com/Ocramius

    http://ocramius.github.com/
  • Rasmus Schultz at May 12, 2016 at 8:51 pm

    What happens if you say <<$x>> and then call $reflection->getAttributes() in your eample? what is $x?

    That is the problem with immediately evaluating everything non "constant". There is no context.
    There's is no context. Annotations should be context-free - that's by design.

    There's also no $this, and no self:: or static:: either, because the
    annotations are supposed to be context-free. They're meta-data, not
    functions - you already have functions, interfaces, abstract methods
    etc. for that.

    Suppose you don't have an instance of a class yet, and you reflect and
    try to get the value of something that requires context - it doesn't
    exist yet. Then what? Obtaining the meta-data before you have an
    instance is a common use-case, for example when generating schema from
    table/column meta-data attached to entities, you don't have an
    instance yet - you're inspecting the class, methods and properties,
    not an object.

    If you insist on putting something in annotations that requires
    context, what you should put in there, is an anonymous function - e.g.
    a function that expects the consumer to provide the context, such that
    you're not dependent on some implied context, instead you're asking
    for a specific context. Dependency injection - good stuff. There's an
    example of that in my comment below the gist.

    Though personally I would never, ever put functionality in an
    annotation - it's a huge misunderstanding, in my opinion. If what you
    wanted was executable functionality that requires a context, what you
    really want is an interface that you can implement. Context requires a
    contract.

    Just my opinion, of course, and there's nothing stopping you from
    using functions if that's your fancy. And it's much safer and
    friendlier to readers, and static analysis tools, not to expect a
    run-time context to always be established by the consumer.

    Either way, the majority use-case is attaching meta-data to
    classes/properties/methods - wanting to attach code and evaluate it at
    run-time is a marginal use-case. Designing the whole thing for that
    first, and sacrificing all the flexibility of the language itself by
    inventing an entirely new concept, which is entirely dependent on
    run-time interpretation, in my opinion, is just completely backwards,
    when you can do something much, much simpler with far more freedom and
    options and design-time safety.

    On Thu, May 12, 2016 at 9:27 PM, Benjamin Eberlei wrote:

    On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz wrote:

    My problem with this PSR is you've created something that strongly
    resembles function or constructor calls, but in reality is just
    key/value pairs.

    Its actually function calls, not constructors calls :-)

    That's confusing in itself, but also puts an unnecessary burden on
    consumers who have to figure out how to map this apparently
    "something" to "something real" - since it really isn't anything other
    than pretty syntax for arrays associated with source-code elements.

    Did anybody look at my notes here?

    https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

    I think this is much simpler and far more flexible - it lets you do
    what you're proposing with attributes (by annotating with simple
    arrays) and also lets you create annotation classes.

    Would anyone care to comment?

    What happens if you say <<$x>> and then call $reflection->getAttributes() in
    your eample? what is $x?

    That is the problem with immediately evaluating everything non "constant".
    There is no context.

    On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta wrote:
    On 12 May 2016 at 16:29, Benjamin Eberlei wrote:
    On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

    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.
    I voted -1

    Reasons: from a Doctrine Annotations maintainer perspective, either
    getting
    a list (without keys) of strings back or ast\nodes are not enough or
    way
    too advanced for our use-case. The middle ground is missing where a
    <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
    nested array, that means getAttributes() does should not only return
    "string" or ast\node as result for each attribute, to there should be a
    way
    to get arrays back.

    Example:

    https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

    greetings
    Benjamin
    Urgh, that is indeed quirky, and makes it unusable.

    Is that an implementation or a spec issue? I know PHP 5.6+ allows array
    constants, but I am not aware of whether that is in the specification.

    Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for
    a
    version that either explicitly contains any constant expression or just
    supports arrays as constants.

    I'll also need to compile the branch and try it out myself before voting
    further: my bad for being hasty.

    Marco Pivetta

    http://twitter.com/Ocramius

    http://ocramius.github.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 10, '16 at 6:29p
activeMay 16, '16 at 1:49a
posts28
users10
websitephp.net

People

Translate

site design / logo © 2018 Grokbase