FAQ

At 17:51 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actually am (either that or get what you want done in some other
way). It's a rare enough use case that I think it's a very reasonable
compromise. The disadvantages of adding a whole new branch of syntax,
for this rare use case, far outweigh its advantages - IMHO.
Rare use case? Have you seen any recent Java framework? Or Java EE 6? Or
design by contract in C#? A declarative programming style can be very
handy.
Framework code (as in code that actually goes into a framework, not code
that uses a framework) represents a tiny percentage of the PHP codebase
at large. Most of it is application code.

You misunderstood me. When I say the frameworks use annotation I don't
mean they use annotations in their own implementation (that's not
particularly relevant for the reason you present).

What I mean is that the frameworks recognize annotations the application
code has so that the framework user can do stuff like injecting objects,
run methods in transactions or check post-conditions in a declarative
fashion, by adding annotations.

By the way, you ignored the rest of the e-mail.

How do you evaluate the complexity/return of features such as annotations
with that of e.g. LSB? Why are they not adequate for PHP, but may be for
other languages?
I do not understand this.

I see no one other than Symfony / Doctrine people pushing for this annotations patch.

How can this special-purpose feature (which would add entirely new language semantics in the form of an embedded micro-language) even be open for discussion, when other, more generally-useful RFCs like http://wiki.php.net/rfc/shortsyntaxforarrays were shot down on the basis that they were hard to read and confusing for new developers?

Sorry, but I don't see how this is even remotely close to being appropriate for PHP. Maybe I'm missing something. :-)

Thanks,
- Nate

Search Discussions

  • Jonathan Bond-Caron at Sep 14, 2010 at 6:30 pm

    On Tue Sep 14 01:25 PM, Nate Abele wrote:

    Sorry, but I don't see how this is even remotely close to being
    appropriate for PHP. Maybe I'm missing something. :-)
    I agree, the use cases are just not there

    Though maybe some form of "annotations" could be useful in php as a
    "pluggable type":
    http://bartoszmilewski.wordpress.com/2009/01/18/java-pluggable-types/

    But this isn't an annotation as just plain metadata, the parser could do
    something with the annotation.

    i.e.

    class Phone {

    @ReadOnly
    public $id;

    @PhoneNumber
    public $number;
    }

    class PhoneNumber implements TypeAnnotation {

    static function getTypeValue($val)
    {
    return preg_replace('~[^0-9]~', '', $val);
    }
    }

    Instead of ~

    class Phone {

    protected $_number;

    function __get($prop) {
    if($prop === 'number')
    return $this->_number;
    }

    function __set($prop, $val) {
    if($prop === 'number')
    $this->_number = preg_replace('~[^0-9]~', '', $val);
    }
    }
  • Pierre Joye at Sep 14, 2010 at 6:48 pm
    hi,
    On Tue, Sep 14, 2010 at 8:30 PM, Jonathan Bond-Caron wrote:
    On Tue Sep 14 01:25 PM, Nate Abele wrote:

    Sorry, but I don't see how this is even remotely close to being
    appropriate for PHP. Maybe I'm missing something. :-)
    I agree, the use cases are just not there
    There are plenty of use cases for that. The main problem I see is that
    nobody seems to have actually used them in other languages, and then
    totally miss why it is a good thing (while not being deadly critical).
    Only the syntax is discussed is somehow disturbing too.

    Cheers,
  • Stas Malyshev at Sep 14, 2010 at 7:01 pm
    Hi!
    There are plenty of use cases for that. The main problem I see is that
    nobody seems to have actually used them in other languages, and then
    Of course not. It couldn't be that your opponents know what they are
    talking about, otherwise they'd agree with you :) Come on. Usefullness
    of annotations in Java (where they are very different, as the language
    is) or C# (which again very different from PHP) or Python (where they
    again work totally different from what is proposed) has nothing to do
    with acceptability of current implementations.
    Is ability to add metadata useful? Of course. But that doesn't mean that
    any proposal implementing metadata automatically gets a pass. We'd be
    better not having it for now than having it wrong - not having can be
    fixed once a good proposal arrives, having it wrong will haunt as forever.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Pierre Joye at Sep 14, 2010 at 7:22 pm
    hi Stas,
    On Tue, Sep 14, 2010 at 9:01 PM, Stas Malyshev wrote:

    Of course not. It couldn't be that your opponents know what they are talking
    about, otherwise they'd agree with you :) Come on. Usefullness of
    annotations in Java (where they are very different, as the language is) or
    C# (which again very different from PHP) or Python (where they again work
    totally different from what is proposed) has nothing to do with
    acceptability of current implementations.
    Is ability to add metadata useful? Of course. But that doesn't mean that any
    proposal implementing metadata automatically gets a pass.
    It is an over interpretation of my reply, which was to a specific mail.

    The additional comment about nobody having used annotations in other
    languages (meaning having annotations experiences, not related to clue
    or lack of clue) was about the proposal like using phpdoc, arguing
    about the syntax endlessly or even worst, one line reply.

    That being said, I'm not proposing it and I'm relatively neutral in
    here. However I am sure that PHP will gain a lot of new nice tools and
    php based services if we support annotations. If this implementation
    is not good enough then let us try to improve it, in the most
    constructive way (that means to leave the other totally unrelated
    topics behind us :).

    Cheers,
  • Pierrick Charron at Sep 14, 2010 at 7:53 pm
    Hi,

    Last year, I attended to a conference where you (Stas) told that the best
    way to do a feature request/proposal was by writing a RFC and a patch even
    if the patch is not perfect. The current implementation may not be perfect
    but it was never said it was a final one. This is a proposal of a first
    implementation which is a start to take people's attention and feedback.

    So the first question that we have to agree is regardless the syntax, and
    the entire implementation do we want to add the ability to add code metadata
    (like annotations) or not into PHP. My opinion is yes. If everybody finds
    this idea stupid then the discussion stops.

    If we agree that Annotations are useful, then I want people who disagree on
    the current implementation to say why they disagree regardless of the
    current syntax (%Annotation !Annotation [Annotation] or whatever it's IMHO a
    detail) and how this implementation could be improved to make it more
    relevant for the PHP needs.

    I can continue working on this patch if people are interested in the main
    idea to improve it (I already plan to improve the patch to include Dmitry's
    feedback). But I expect to get constructive feedback on how it could be
    improved instead of just a discussion on why this feature is accepted and
    others are not (we are not childs), or I don't like the current
    implementation without any valid reason but the syntax etc.

    Regards,
    Pierrick

    2010/9/14 Stas Malyshev <smalyshev@sugarcrm.com>
    Hi!


    There are plenty of use cases for that. The main problem I see is that
    nobody seems to have actually used them in other languages, and then
    Of course not. It couldn't be that your opponents know what they are
    talking about, otherwise they'd agree with you :) Come on. Usefullness of
    annotations in Java (where they are very different, as the language is) or
    C# (which again very different from PHP) or Python (where they again work
    totally different from what is proposed) has nothing to do with
    acceptability of current implementations.
    Is ability to add metadata useful? Of course. But that doesn't mean that
    any proposal implementing metadata automatically gets a pass. We'd be better
    not having it for now than having it wrong - not having can be fixed once a
    good proposal arrives, having it wrong will haunt as forever.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stas Malyshev at Sep 14, 2010 at 8:12 pm
    Hi!
    Last year, I attended to a conference where you (Stas) told that the
    best way to do a feature request/proposal was by writing a RFC and a
    patch even if the patch is not perfect. The current implementation may
    not be perfect but it was never said it was a final one. This is a
    proposal of a first implementation which is a start to take people's
    attention and feedback.
    Of course, writing an RFC and a patch is a good way to start the process
    and I think it is great you did it. However it doesn't mean any
    RFC/patch will be accepted. That's why we discuss it - and there's no
    guarantee that the result would be acceptance. Rodin said he makes
    sculpture by chopping off extra pieces from the block of marble. We need
    to chop off stuff too sometimes if we want the language to stay easy to
    learn, read and use.
    So the first question that we have to agree is regardless the syntax,
    and the entire implementation do we want to add the ability to add code
    metadata (like annotations) or not into PHP. My opinion is yes. If
    everybody finds this idea stupid then the discussion stops.
    I think we _already_ have metadata in PHP, albeit done through phpdocs.
    So the question is kind of moot :) We should see if it's enough for us
    or we want to add/change/extend it and if so, how.

    I however have some doubts about usefullness of "code" metadata - i.e.
    code being run as part of metadata processing in the language. Having
    purely declarative metadata you can always have user code run on it and
    do any logic you want, but having "active" metadata seems to me to have
    high potential for complications.

    Speaking of syntax, I think it is important too, because syntax defines
    readability and usability of the language. And unobvious syntax rules
    for different parts of the language hurts that.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Pierre Joye at Sep 14, 2010 at 8:37 pm
    hi,
    On Tue, Sep 14, 2010 at 10:12 PM, Stas Malyshev wrote:

    I think we _already_ have metadata in PHP, albeit done through phpdocs. So
    the question is kind of moot :) We should see if it's enough for us or we
    want to add/change/extend it and if so, how.
    I think we have the main issue here, it has absolutely nothing to do
    with users documentation, as phpdoc does. Yes, they both somehow
    'document' something but still totally unrelated for the goals and
    usages. To understand that would help to move forward.

    Cheers,
  • Stas Malyshev at Sep 15, 2010 at 6:09 am
    Hi!
    I think we have the main issue here, it has absolutely nothing to do
    with users documentation, as phpdoc does. Yes, they both somehow
    'document' something but still totally unrelated for the goals and
    usages. To understand that would help to move forward.
    Phpdocs aren't "user documentation" only, not for a long time (I mean
    the concept, not the particular application called phpDocumentor, of
    course). They are being used as metadata in many places. You could argue
    that's misguided but you can't ignore the fact that's what people do.
    The "goals and usages" of those tags are exactly metadata - and
    regardless of the annotations, I'd be happy if Reflection recognized it
    finally (by integrating some kind of phpdoc tag parser).

    In general, I don't see why metadata written as /** @data */ is that
    much worse than metadata written as [data()]. Can you explain?
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Zeev Suraski at Sep 15, 2010 at 6:56 am

    At 08:09 15/09/2010, Stas Malyshev wrote:
    Phpdocs aren't "user documentation" only, not for a long time (I
    mean the concept, not the particular application called
    phpDocumentor, of course). They are being used as metadata in many
    places. You could argue that's misguided but you can't ignore the
    fact that's what people do. The "goals and usages" of those tags are
    exactly metadata - and regardless of the annotations, I'd be happy
    if Reflection recognized it finally (by integrating some kind of
    phpdoc tag parser).
    I second that word for word. FWIW, I don't see it as misguided at all.

    Zeev
  • Benjamin Eberlei at Sep 15, 2010 at 8:45 am
    Hi Zeev and Stas,

    I wouldnt mind extending doc block metadata support instead of adding a
    new syntax.

    I agree with you that PHP Docs allow metadata and they can be used for
    that (and some people do, including me), however what the annotation patch
    + rfc tries to achieve is something going beyong $refl->getDocComment()
    returning a string only. The string only return leads to hunderets of
    different approaches for annotating metadata in all the different
    frameworks and libraries. A single unified syntax would be benefitial.

    That is why I don't know if it will even be possible to extend the doc
    blocks in a generic way that does not break half the applications out
    there.

    When extending doc-blocks there is probably new method required
    $refl->getParsedDocComment() which then returns an array of metadata for
    that particular refl instance. Now here the syntax would be a problem, can
    we find something that does not break for all the different usages of
    docblocks out there? Since the method/parsing would be nested, on request
    only it wouldnt break any application that does not use parsed doc
    comments. However for applications that do, a syntax needs to be found
    that:

    1. does not break for various type hinting doc syntaxes
    2. does not break for various commenting styles

    Can someone come up with additional pitfalls?

    greetings,
    Benjamin

    On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraski wrote:

    At 08:09 15/09/2010, Stas Malyshev wrote:

    Phpdocs aren't "user documentation" only, not for a long time (I
    mean the concept, not the particular application called phpDocumentor, of
    course). They are being used as metadata in many places. You could argue
    that's misguided but you can't ignore the fact that's what people do. The
    "goals and usages" of those tags are exactly metadata - and regardless of
    the annotations, I'd be happy if Reflection recognized it finally (by
    integrating some kind of phpdoc tag parser).

    I second that word for word. FWIW, I don't see it as misguided at all.
    Zeev
  • Lars Schultz at Sep 15, 2010 at 9:46 am
    listen to this man;) I think he's on to something. I don't see any
    problem with that aproach and both parties would be satisfied, no?

    Am 15.09.2010 10:45, schrieb Benjamin Eberlei:
    Hi Zeev and Stas,



    I wouldnt mind extending doc block metadata support instead of adding a

    new syntax.



    I agree with you that PHP Docs allow metadata and they can be used for

    that (and some people do, including me), however what the annotation patch

    + rfc tries to achieve is something going beyong $refl->getDocComment()

    returning a string only. The string only return leads to hunderets of

    different approaches for annotating metadata in all the different

    frameworks and libraries. A single unified syntax would be benefitial.



    That is why I don't know if it will even be possible to extend the doc

    blocks in a generic way that does not break half the applications out

    there.



    When extending doc-blocks there is probably new method required

    $refl->getParsedDocComment() which then returns an array of metadata for

    that particular refl instance. Now here the syntax would be a problem, can

    we find something that does not break for all the different usages of

    docblocks out there? Since the method/parsing would be nested, on request

    only it wouldnt break any application that does not use parsed doc

    comments. However for applications that do, a syntax needs to be found

    that:



    1. does not break for various type hinting doc syntaxes

    2. does not break for various commenting styles



    Can someone come up with additional pitfalls?



    greetings,

    Benjamin



    On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraskiwrote:



    At 08:09 15/09/2010, Stas Malyshev wrote:



    Phpdocs aren't "user documentation" only, not for a long time (I

    mean the concept, not the particular application called phpDocumentor, of

    course). They are being used as metadata in many places. You could argue

    that's misguided but you can't ignore the fact that's what people do. The

    "goals and usages" of those tags are exactly metadata - and regardless of

    the annotations, I'd be happy if Reflection recognized it finally (by

    integrating some kind of phpdoc tag parser).



    I second that word for word. FWIW, I don't see it as misguided at all.

    Zeev
  • Guilherme Blanco at Sep 15, 2010 at 4:17 pm
    It's curious that you keep complaining about new syntax and propose a
    new one at the same time.

    [Foo] introduces new concept, use /** @Foo */ or /** [Foo] */ instead.
    What's the point then?

    I think meta programming is not and would never be part of comment.
    As previously said, docblock means documentation, without any meaning
    to parser, entirely human readable and totally removable without
    affecting overall execution.
    Something that HAS a meaning to execution means something out of the
    userland comments. Point made.

    Cheers,
    On Wed, Sep 15, 2010 at 6:45 AM, Lars Schultz wrote:
    listen to this man;) I think he's on to something. I don't see any problem
    with that aproach and both parties would be satisfied, no?

    Am 15.09.2010 10:45, schrieb Benjamin Eberlei:
    Hi Zeev and Stas,



    I wouldnt mind extending doc block metadata support instead of adding a

    new syntax.



    I agree with you that PHP Docs allow metadata and they can be used for

    that (and some people do, including me), however what the annotation patch

    + rfc tries to achieve is something going beyong $refl->getDocComment()

    returning a string only. The string only return leads to hunderets of

    different approaches for annotating metadata in all the different

    frameworks and libraries. A single unified syntax would be benefitial.



    That is why I don't know if it will even be possible to extend the doc

    blocks in a generic way that does not break half the applications out

    there.



    When extending doc-blocks there is probably new method required

    $refl->getParsedDocComment() which then returns an array of metadata for

    that particular refl instance. Now here the syntax would be a problem, can

    we find something that does not break for all the different usages of

    docblocks out there? Since the method/parsing would be nested, on request

    only it wouldnt break any application that does not use parsed doc

    comments. However for applications that do, a syntax needs to be found

    that:



    1. does not break for various type hinting doc syntaxes

    2. does not break for various commenting styles



    Can someone come up with additional pitfalls?



    greetings,

    Benjamin



    On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraskiwrote:



    At 08:09 15/09/2010, Stas Malyshev wrote:



    Phpdocs aren't "user documentation" only, not for a long time (I

    mean the concept, not the particular application called phpDocumentor, of

    course). They are being used as metadata in many places. You could argue

    that's misguided but you can't ignore the fact that's what people do. The

    "goals and usages" of those tags are exactly metadata - and regardless of

    the annotations, I'd be happy if Reflection recognized it finally (by

    integrating some kind of phpdoc tag parser).



    I second that word for word. FWIW, I don't see it as misguided at all.

    Zeev

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Guilherme Blanco
    Mobile: +55 (16) 9215-8480
    MSN: guilhermeblanco@hotmail.com
    São Paulo - SP/Brazil
  • James Butler at Sep 15, 2010 at 4:24 pm
    I might be wading into this a bit fast but....

    At a very simple level, comments are not meant to be parsed by design. Hence commenting out code so it is not parsed!
    How would one tell the parser not to read docblock annotations as there wouldn't be a mechanism to comment them out?
    Lots of people use comments to stop some of their code being executed for testing etc.

    I'm indifferent currently towards annotations and their usefulness but I really don't think they should sit in comments....

    -----Original Message-----
    From: Guilherme Blanco
    Sent: 15 September 2010 17:18
    To: Lars Schultz
    Cc: internals@lists.php.net
    Subject: Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch

    It's curious that you keep complaining about new syntax and propose a
    new one at the same time.

    [Foo] introduces new concept, use /** @Foo */ or /** [Foo] */ instead.
    What's the point then?

    I think meta programming is not and would never be part of comment.
    As previously said, docblock means documentation, without any meaning
    to parser, entirely human readable and totally removable without
    affecting overall execution.
    Something that HAS a meaning to execution means something out of the
    userland comments. Point made.

    Cheers,
    On Wed, Sep 15, 2010 at 6:45 AM, Lars Schultz wrote:
    listen to this man;) I think he's on to something. I don't see any problem
    with that aproach and both parties would be satisfied, no?

    Am 15.09.2010 10:45, schrieb Benjamin Eberlei:
    Hi Zeev and Stas,



    I wouldnt mind extending doc block metadata support instead of adding a

    new syntax.



    I agree with you that PHP Docs allow metadata and they can be used for

    that (and some people do, including me), however what the annotation patch

    + rfc tries to achieve is something going beyong $refl->getDocComment()

    returning a string only. The string only return leads to hunderets of

    different approaches for annotating metadata in all the different

    frameworks and libraries. A single unified syntax would be benefitial.



    That is why I don't know if it will even be possible to extend the doc

    blocks in a generic way that does not break half the applications out

    there.



    When extending doc-blocks there is probably new method required

    $refl->getParsedDocComment() which then returns an array of metadata for

    that particular refl instance. Now here the syntax would be a problem, can

    we find something that does not break for all the different usages of

    docblocks out there? Since the method/parsing would be nested, on request

    only it wouldnt break any application that does not use parsed doc

    comments. However for applications that do, a syntax needs to be found

    that:



    1. does not break for various type hinting doc syntaxes

    2. does not break for various commenting styles



    Can someone come up with additional pitfalls?



    greetings,

    Benjamin



    On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraskiwrote:



    At 08:09 15/09/2010, Stas Malyshev wrote:



    Phpdocs aren't "user documentation" only, not for a long time (I

    mean the concept, not the particular application called phpDocumentor, of

    course). They are being used as metadata in many places. You could argue

    that's misguided but you can't ignore the fact that's what people do. The

    "goals and usages" of those tags are exactly metadata - and regardless of

    the annotations, I'd be happy if Reflection recognized it finally (by

    integrating some kind of phpdoc tag parser).



    I second that word for word. FWIW, I don't see it as misguided at all.

    Zeev

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Guilherme Blanco
    Mobile: +55 (16) 9215-8480
    MSN: guilhermeblanco@hotmail.com
    São Paulo - SP/Brazil

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Chad Fulton at Sep 15, 2010 at 4:50 pm
    Since the parsed version of the docblock would only be accessible
    through a reflection method, you would have to specifically request it
    for it to be parsed and given to you as an object or array. Also, it
    would only be parsed, not executed; I don't think that this is
    proposing executing comment blocks.

    I for one would give a huge +1 to adding a function which parses
    docblocks. I would love to see a simple approach, like the one below:

    A docblock like the following:

    /**
    * (Short Description of the DocBlock)
    *
    * (Long Description of the DocBlock ...
    * continues...
    *
    * continues...)
    *
    * @tag1 value1
    * @tag2 value2
    * @tag3 value3
    */

    Would be parsed to return an array or object like the following:

    Array (
    'short_description' => ' (Short Description of the DocBlock) ',
    'long_description' => ' (Long Description of the DocBlock
    ...\ncontinues...\n\ncontinues... ',
    'tags' => array(
    'tag1' => 'value1',
    'tag2' => 'value2',
    'tag3' => 'value3,
    )
    )

    The actual rules could be whatever people like most (I think JavaDoc
    has some fairly explicit rules that could be borrowed from). I would
    be happy to write an RFC laying out a sample if there is any interest
    in this, although I don't have permissions to post it on the wiki.

    This would *also* introduce new syntax into PHP. However, this syntax
    is widely used already, I think.

    It would be backwards compatible for current implementations already
    using the docblocks, since they could continue to use
    Reflection::getDocComment() to retrieve the string (and of course
    phpDocumenter uses tokenizer, I think).

    I think that for the use cases mentioned, there is no great win to be
    had by having the PHP engine instantiate objects automatically. The
    most important problem that I think people are asking for annotations
    to solve is that there is no standardized way to read elements'
    metadata, and there are simple, effective ways to do it (e.g. the
    above).

    At the very least, I think that this would be a nice feature even if
    annotations as a language structure were to be implemented in the
    future, and the parsed docblocks would give us more information about
    what works and what doesn't.

    On Wed, Sep 15, 2010 at 9:22 AM, James Butler
    wrote:
    I might be wading into this a bit fast but....

    At a very simple level, comments are not meant to be parsed by design. Hence commenting out code so it is not parsed!
    How would one tell the parser not to read docblock annotations as there wouldn't be a mechanism to comment them out?
    Lots of people use comments to stop some of their code being executed for testing etc.

    I'm indifferent currently towards annotations and their usefulness but I really don't think they should sit in comments....

    -----Original Message-----
    From: Guilherme Blanco
    Sent: 15 September 2010 17:18
    To: Lars Schultz
    Cc: internals@lists.php.net
    Subject: Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch

    It's curious that you keep complaining about new syntax and propose a
    new one at the same time.

    [Foo] introduces new concept, use /** @Foo */  or /** [Foo] */ instead.
    What's the point then?

    I think meta programming is not and would never be part of comment.
    As previously said, docblock means documentation, without any meaning
    to parser, entirely human readable and totally removable without
    affecting overall execution.
    Something that HAS a meaning to execution means something out of the
    userland comments. Point made.

    Cheers,
    On Wed, Sep 15, 2010 at 6:45 AM, Lars Schultz wrote:
    listen to this man;) I think he's on to something. I don't see any problem
    with that aproach and both parties would be satisfied, no?

    Am 15.09.2010 10:45, schrieb Benjamin Eberlei:
    Hi Zeev and Stas,



    I wouldnt mind extending doc block metadata support instead of adding a

    new syntax.



    I agree with you that PHP Docs allow metadata and they can be used for

    that (and some people do, including me), however what the annotation patch

    + rfc tries to achieve is something going beyong $refl->getDocComment()

    returning a string only. The string only return leads to hunderets of

    different approaches for annotating metadata in all the different

    frameworks and libraries. A single unified syntax would be benefitial.



    That is why I don't know if it will even be possible to extend the doc

    blocks in a generic way that does not break half the applications out

    there.



    When extending doc-blocks there is probably new method required

    $refl->getParsedDocComment() which then returns an array of metadata for

    that particular refl instance. Now here the syntax would be a problem, can

    we find something that does not break for all the different usages of

    docblocks out there? Since the method/parsing would be nested, on request

    only it wouldnt break any application that does not use parsed doc

    comments. However for applications that do, a syntax needs to be found

    that:



    1. does not break for various type hinting doc syntaxes

    2. does not break for various commenting styles



    Can someone come up with additional pitfalls?



    greetings,

    Benjamin



    On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraskiwrote:



    At 08:09 15/09/2010, Stas Malyshev wrote:



    Phpdocs aren't "user documentation" only, not for a long time (I

    mean the concept, not the particular application called phpDocumentor, of

    course). They are being used as metadata in many places. You could argue

    that's misguided but you can't ignore the fact that's what people do. The

    "goals and usages" of those tags are exactly metadata - and regardless of

    the annotations, I'd be happy if Reflection recognized it finally (by

    integrating some kind of phpdoc tag parser).



    I second that word for word. FWIW, I don't see it as misguided at all.

    Zeev

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Guilherme Blanco
    Mobile: +55 (16) 9215-8480
    MSN: guilhermeblanco@hotmail.com
    São Paulo - SP/Brazil

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jonathan Bond-Caron at Sep 15, 2010 at 8:05 pm

    On Wed Sep 15 12:17 PM, Guilherme Blanco wrote:
    I think meta programming is not and would never be part of comment.
    As previously said, docblock means documentation, without any meaning
    to parser, entirely human readable and totally removable without
    affecting overall execution.
    I have to agree here, there's lots of php tools that 'strip comments'.

    If you strip comments, you'd be effectively removing 'annotations' which changes how that code would run in a given framework or tool. It kind of defeats the purpose.

    But my opinion as an end user and framework developer:

    the rfc really needs to elaborate on the use cases *specific to php*

    java has some here:
    http://jcp.org/en/jsr/detail?id=250

    Does php need to be become this complicated?

    I worry about how php can grow complicated to a point where you won't be able to use it without using tool or framework X.
    I'll use .NET, thank you very much.
  • Arvids Godjuks at Sep 15, 2010 at 8:27 pm
    Hi all.

    As a user land developer and active reader (and some times poster) for
    a few years now this is the first time I trully don't understand what
    the hell are you talking about and what are annotations at all and
    what will be the usage of them in the PHP. And for what? Building 2-3
    frameworks and that's all (as I understand from reading this
    discussion)?

    I'm sure pretty much user land developers read this thread and ask
    themselves the same question.

    P.S. Personally I would take the energy boiling in this thread and
    throw it at solving the windows biuld and PECL problem. Right now you
    can't install PHP 5.2 and apache on a Windows 7 - it just crashes
    totally. Only 5.3 works, not to mention much of the PECL libs just
    don't have dll's (lucky if you find one in the Google). The same goes
    for the PECL dll's for 5.3 - all of them, excluding the standard once,
    mostly are missing and can't be found at all.
  • Ferenc Kovacs at Sep 16, 2010 at 8:05 am

    On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks wrote:

    Hi all.

    As a user land developer and active reader (and some times poster) for
    a few years now this is the first time I trully don't understand what
    the hell are you talking about and what are annotations at all and
    what will be the usage of them in the PHP. And for what? Building 2-3
    frameworks and that's all (as I understand from reading this
    discussion)?
    Did you read the quoted references in this thread?
    It's a new feature proposal as for example closures or traits, if you don't
    know what are they, you have to do some work to understand them, but thats
    all.
    You should understand the discussion, before choosing your side.

    I'm sure pretty much user land developers read this thread and ask
    themselves the same question.
    dunno, I'm a user land developer, and I don't ask the same question, so it's
    1:1 for now.

    P.S. Personally I would take the energy boiling in this thread and
    throw it at solving the windows biuld and PECL problem. Right now you
    can't install PHP 5.2 and apache on a Windows 7 - it just crashes
    totally. Only 5.3 works, not to mention much of the PECL libs just
    don't have dll's (lucky if you find one in the Google). The same goes
    for the PECL dll's for 5.3 - all of them, excluding the standard once,
    mostly are missing and can't be found at all.
    party agree here, feel free to open a new thread or issue, but one problem
    doesn't mean, that we can't discuss other ideas, until that problem is
    fixed.

    Tyrael
  • Pierre Joye at Sep 16, 2010 at 8:21 am

    On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks wrote:

    P.S. Personally I would take the energy boiling in this thread and
    throw it at solving the windows biuld and PECL problem. Right now you
    can't install PHP 5.2 and apache on a Windows 7 - it just crashes
    totally.
    Where are the bugs report?
    Only 5.3 works, not to mention much of the PECL libs just
    don't have dll's (lucky if you find one in the Google). The same goes
    for the PECL dll's for 5.3 - all of them, excluding the standard once,
    mostly are missing and can't be found at all.
    What are you talking about? Not a real question, use bugs.php.net for
    php extensions, if something is broken or missing.

    Thanks to focus on the topic and not hi jack this thread with random rants.

    Cheers,
  • Aleksei Sapunov at Sep 16, 2010 at 8:27 am
    Hello all,
    Only today see that here is very intersting discussion.
    I have a question: why was choosed exactly this format (seems like c#-like,
    not java-like)?
    Simply [] is used for arrays. Why not use @ at annotation name?

    2010/9/16 Pierre Joye <pierre.php@gmail.com>
    On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
    wrote:
    P.S. Personally I would take the energy boiling in this thread and
    throw it at solving the windows biuld and PECL problem. Right now you
    can't install PHP 5.2 and apache on a Windows 7 - it just crashes
    totally.
    Where are the bugs report?
    Only 5.3 works, not to mention much of the PECL libs just
    don't have dll's (lucky if you find one in the Google). The same goes
    for the PECL dll's for 5.3 - all of them, excluding the standard once,
    mostly are missing and can't be found at all.
    What are you talking about? Not a real question, use bugs.php.net for
    php extensions, if something is broken or missing.

    Thanks to focus on the topic and not hi jack this thread with random rants.

    Cheers,
    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Christian Kaps at Sep 16, 2010 at 8:32 am
    Hi,

    it's reserved for the error control
    operator(http://www.php.net/manual/en/language.operators.errorcontrol.php).

    Greetings,
    Christian
    On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov wrote:
    Hello all,
    Only today see that here is very intersting discussion.
    I have a question: why was choosed exactly this format (seems like c#-like,
    not java-like)?
    Simply [] is used for arrays. Why not use @ at annotation name?

    2010/9/16 Pierre Joye <pierre.php@gmail.com>
    On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
    wrote:
    P.S. Personally I would take the energy boiling in this thread and
    throw it at solving the windows biuld and PECL problem. Right now you
    can't install PHP 5.2 and apache on a Windows 7 - it just crashes
    totally.
    Where are the bugs report?
    Only 5.3 works, not to mention much of the PECL libs just
    don't have dll's (lucky if you find one in the Google). The same goes
    for the PECL dll's for 5.3 - all of them, excluding the standard once,
    mostly are missing and can't be found at all.
    What are you talking about? Not a real question, use bugs.php.net for
    php extensions, if something is broken or missing.

    Thanks to focus on the topic and not hi jack this thread with random rants.

    Cheers,
    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Aleksei Sapunov at Sep 16, 2010 at 8:40 am
    Hi,
    Yes, you right. But [] are used in arrays definition. If take in to account
    that format with @ is more readable?

    Is it a problem to implement it using @ symbol?

    2010/9/16 Christian Kaps <christian.kaps@mohiva.com>
    Hi,

    it's reserved for the error control
    operator(http://www.php.net/manual/en/language.operators.errorcontrol.php
    ).

    Greetings,
    Christian
    On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov wrote:
    Hello all,
    Only today see that here is very intersting discussion.
    I have a question: why was choosed exactly this format (seems like c#-like,
    not java-like)?
    Simply [] is used for arrays. Why not use @ at annotation name?

    2010/9/16 Pierre Joye <pierre.php@gmail.com>
    On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
    wrote:
    P.S. Personally I would take the energy boiling in this thread and
    throw it at solving the windows biuld and PECL problem. Right now you
    can't install PHP 5.2 and apache on a Windows 7 - it just crashes
    totally.
    Where are the bugs report?
    Only 5.3 works, not to mention much of the PECL libs just
    don't have dll's (lucky if you find one in the Google). The same goes
    for the PECL dll's for 5.3 - all of them, excluding the standard once,
    mostly are missing and can't be found at all.
    What are you talking about? Not a real question, use bugs.php.net for
    php extensions, if something is broken or missing.

    Thanks to focus on the topic and not hi jack this thread with random
    rants.
    Cheers,
    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Adam Harvey at Sep 16, 2010 at 8:44 am

    On 16 September 2010 16:40, Aleksei Sapunov wrote:
    Hi,
    Yes, you right. But [] are used in arrays definition. If take in to account
    that format with @ is more readable?

    Is it a problem to implement it using @ symbol?
    If we're down to bickering about the finer points of the syntax, can
    we just have a vote already? Please?

    Adam
  • Jussi Vaihia at Sep 16, 2010 at 12:26 pm
    Tangent:

    Could PHP as a language be kept "pure" by first implementing python
    decorators*, then implement annotations using a purpose-built
    decorator?

    @annotate(PHP-code-goes-here)
    function framework_call(request) { ... }

    * http://www.python.org/dev/peps/pep-0318/
  • Stas Malyshev at Sep 16, 2010 at 5:49 pm
    Hi!
    Could PHP as a language be kept "pure" by first implementing python
    decorators*, then implement annotations using a purpose-built
    decorator?
    No, we can't have python decorators because unlike Python PHP functions
    and classes aren't first-class objects. In Python, this:

    @dec2
    @dec1
    def func(arg1, arg2, ...):
    pass

    means this:

    def func(arg1, arg2, ...):
    pass
    func = dec2(dec1(func))

    However, you can't write equivalent code in PHP.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Ionut G. Stan at Sep 16, 2010 at 6:23 pm

    On 16/Sep/10 8:49 PM, Stas Malyshev wrote:
    No, we can't have python decorators because unlike Python PHP functions
    and classes aren't first-class objects. In Python, this:

    @dec2
    @dec1
    def func(arg1, arg2, ...):
    pass

    means this:

    def func(arg1, arg2, ...):
    pass
    func = dec2(dec1(func))

    However, you can't write equivalent code in PHP.
    I had the same idea regarding decorators, and I saw the same problem
    that you see, functions are not first-class citizens in PHP. I was
    wondering, though, whether the possibility to assign expressions to
    constants couldn't change that. Let me explain a little what I'm
    thinking exactly.

    Currently, PHP supports lambda expressions and they're pretty much as
    first-class citizens as possible. PHP, also supports variable functions
    in an attempt to make global functions look like they'd be first-class
    citizens.

    So, the following snippet isn't yet working, but AFAIK it will work in
    the next PHP release:


    function foo() {
    echo "foo was called";
    }

    function bar() {
    return 'foo';
    }

    bar()(); // prints "foo was called";


    Now, assume I define this constant:

    define('foo', 'foo');

    Now I can write:


    function bar() {
    return foo;
    }

    And the "foo" function will look more like a first-class citizens.
    But, how about being able to write:

    const foo = function () use ($globalVar) {

    };

    which would be the desugaring of:

    function foo () {
    global $globalVar;
    }

    Now foo would be an instance of Closure, and would allow us to pass it
    around free.


    Does that make any sense to any of you? Is it at least possible with the
    current Zend Engine implementation? What problems would it pose?


    Getting back to decorators...

    Having the above syntax, we would be able to write:

    const func = dec2(dec1(function () {

    }));

    which can be further sugared to some decorator specific syntax.


    I guess the gist of my whole email is that it would be nice to get rid
    of the dollar sign in identifiers that designate lambda expressions.
    That would somehow level things up.

    --
    Ionuț G. Stan | http://igstan.ro
  • Stas Malyshev at Sep 16, 2010 at 6:35 pm
    Hi!
    const foo = function () use ($globalVar) {

    };
    How would you call this thing? foo()? Then you have a problem - foo()
    already has meaning, and it's "call function named foo", not "get
    constant named foo and call function inside if it's there". Also, it
    would work different from variables: for variables, these both work:

    $foo1 = "foo"; $foo1();
    $foo1 = function() {}; $foo1();

    But for constants the first form wouldn't work - unless you also make
    foo() mean "check constant foo and if it's a string then call function
    with the name that equals to its value" - which adds a lot of complexity
    there.

    Also note, that const expressions can be used in defaults now
    (properties, parameters, etc.) - and that means they are cacheable. But
    Closures aren't cacheable and couldn't be used in defaults - that means
    you'd be introducing two types of const expressions - the "real const"
    and the "as if" const.
    I do not see it working.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Alexey Zakhlestin at Sep 18, 2010 at 10:47 am

    On Thu, Sep 16, 2010 at 10:35 PM, Stas Malyshev wrote:
    Hi!
    const foo = function () use ($globalVar) {

    };
    How would you call this thing? foo()? Then you have a problem - foo()
    already has meaning, and it's "call function named foo", not "get constant
    named foo and call function inside if it's there".
    His idea is, that "get constant named foo and call function inside if
    it's there" should be the only meaning
    and "function foo() {}" should be syntactic sugar for defining
    constant foo with closure inside.

    --
    Alexey Zakhlestin
    http://www.milkfarmsoft.com/
  • Jussi Vaihia at Sep 16, 2010 at 8:58 pm
    Good reminder, thanks! Implementation would indeed require support
    from PHP, say:

    // magic-method __decorate implies that __construct would return
    $this->__decorate(func_get_args(), $f); and enforce @ as
    annotation-syntax
    class Dec1 {
    function __decorate($args, $f) {
    return $f;
    }
    }
    class Dec2 { ... }

    @dec2
    @dec1
    function foo() {}

    means this:

    $foo = new Dec2(new Dec1(new ReflectionFunction('foo')));
    Perhaps ... $foo = @Dec2(@Dec1(new ReflectionFunction('foo')));
    On Thu, Sep 16, 2010 at 8:49 PM, Stas Malyshev wrote:
    Hi!
    Could PHP as a language be kept "pure" by first implementing python
    decorators*, then implement annotations using a purpose-built
    decorator?
    No, we can't have python decorators because unlike Python PHP functions and
    classes aren't first-class objects. In Python, this:

    @dec2
    @dec1
    def func(arg1, arg2, ...):
    pass

    means this:

    def func(arg1, arg2, ...):
    pass
    func = dec2(dec1(func))

    However, you can't write equivalent code in PHP.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Rafael Dohms at Sep 16, 2010 at 1:43 pm

    On Wed, Sep 15, 2010 at 5:27 PM, Arvids Godjuks wrote:
    Hi all.

    As a user land developer and active reader (and some times poster) for
    a few years now this is the first time I trully don't understand what
    the hell are you talking about and what are annotations at all and
    what will be the usage of them in the PHP. And for what? Building 2-3
    frameworks and that's all (as I understand from reading this
    discussion)?
    As a userland user also, its about much more then this, and still, if
    its just for these frameworks, i'm a user of these frameworks,
    anything that makes it easier for me to use them or make them faster,
    i'm in for it. Like the doctrine example, adding a ORM layer on top of
    my objects just by adding annotations an not extending objects and
    such is a huge gain in my applications.
    I'm sure pretty much user land developers read this thread and ask
    themselves the same question.
    I'm also NOT asking myself this question, so its looks like 2:1 as
    mentioned above by Tyrael

    Also, discussing one interest does not stop work on all of the other
    features/bugs the amount of people reading and discussing here is a
    small percentage of the team that works on PHP.

    --
    Rafael Dohms
    PHP Evangelist and Community Leader
    http://www.rafaeldohms.com.br
    http://www.phpsp.org.br
  • Gustavo Lopes at Sep 15, 2010 at 7:24 pm

    On Wed, 15 Sep 2010 07:55:55 +0100, Zeev Suraski wrote:
    At 08:09 15/09/2010, Stas Malyshev wrote:
    Phpdocs aren't "user documentation" only, not for a long time (I mean
    the concept, not the particular application called phpDocumentor, of
    course). They are being used as metadata in many places. You could
    argue that's misguided but you can't ignore the fact that's what people
    do. The "goals and usages" of those tags are exactly metadata - and
    regardless of the annotations, I'd be happy if Reflection recognized it
    finally (by integrating some kind of phpdoc tag parser).
    I second that word for word. FWIW, I don't see it as misguided at all.
    OK, here's why "doc comments" are insufficient:

    1. You have to manually parse them (which is not easy; writing parsers is
    quite error prone). You would also probably need to implement some form of
    annotation inheritance.
    2. There's no standardized way to express annotations, so the user will
    have to learn a new syntax for each implementation.
    3. Performance issues -- you to have to parse and validate the annotations
    on each request, unless you implement your own caching mechanism. With
    native annotations, you could use opcode caches to do parsing and
    validation only on the first request.
    4. Finally, and this is the most significant to me -- since PHP doesn't
    know annotations (it only knows there's a blob a text), you cannot give to
    certain annotations a meaning that would be recognized at an engine. With
    annotations, we could, in the future, implement a special meaning for
    @ReadOnly and @WriteOnly for properties and have stuff like:

    @RunBefore("Log::writeMessage")
    public LogAnnotation extends ReflectionAnnotation {
    public $value;
    }
    ...

    @Log("Enterting method Foo::bar")
    @RequiredRole("moderator")
    public function bar() { }

    without having to run the method through a framework that would recognize
    those annotations in doc blocks. However, the only thing close to this in
    the current implementation is @Inherited.


    Finally, a separate issue is the syntactic one. Could we use the current
    implementation but define the annotations in doc blocks instead?

    If it comes to that, it'd be better than nothing. However, It would almost
    certainly break BC (and subjectively, it feels wrong to mix annotations,
    which have real impact on the application, with mere comments).

    If the annotations were parsed only on request, it would not break BC in
    the sense that whole old applications would stop working; however, when
    upgrading PHP and the framework to a new version that would support
    annotations, it could misinterpret old doc comments that look like
    annotations (or most likely, malformed annotations). More importantly, it
    would break a compelling reason to have annotations (point 4.).


    --
    Gustavo Lopes
  • Christian Kaps at Sep 15, 2010 at 5:33 am

    Am 14.09.2010 22:12, schrieb Stas Malyshev:
    I think we _already_ have metadata in PHP, albeit done through
    phpdocs. So the question is kind of moot :) We should see if it's
    enough for us or we want to add/change/extend it and if so, how.
    Hi,

    in my mind there is a big mistake when using annotations in PHPDoc comments.

    As example let as use a JSR 303 - Bean Validator like Hibernate
    Validator for PHP.

    namespace my\project\models\dto;

    class User {

    /**
    * @com\jsr303\validator\constraints\NotNull
    * @com\jsr303\validator\constraints\Integer
    */
    public $id;

    /**
    * @com\jsr303\validator\constraints\NotNull
    * @com\jsr303\validator\constraints\Regexp('/[a-z]*/i')
    * @com\jsr303\validator\constraints\MinLength(2)
    * @com\jsr303\validator\constraints\MaxLength(255)
    */
    public $name;

    /**
    * @com\jsr303\validator\constraints\NotNull
    * @my\project\validator\constraints\Zipcode
    */
    public $zipcode;
    }

    It is possible to use this type of annotations but it is impracticable.
    An other problem is that every framework use its one annotation syntax.
    So it makes the framework end user more confusing as using a clear
    unique syntax.

    I think the PHP way should be as in the next example.

    namespace my\project\models\dto;

    use com\jsr303\validator\constraints\NotNull;
    use com\jsr303\validator\constraints\Integer;
    use com\jsr303\validator\constraints\Regexp;
    use com\jsr303\validator\constraints\MinLength;
    use com\jsr303\validator\constraints\MaxLength;
    use my\project\validator\constraints\Zipcode;

    class User {

    [NotNull]
    [Integer]
    public $id;

    [NotNull]
    [Regexp('/[a-z]*/i')]
    [MinLength(2)]
    [MaxLength(255)]
    public $name;

    [NotNull]
    [Zipcode]
    public $zipcode;
    }

    With this out of the box PHP annotations it makes it possible to create
    powerful frameworks which can used by a great range of developers
    without learning a new syntax for it. Pleas do not argue about thy
    syntax of the annotation because this isn't final.

    Greetings,
    Christian
  • Stas Malyshev at Sep 15, 2010 at 6:09 am
    Hi!
    class User {

    [NotNull]
    [Integer]
    public $id;

    [NotNull]
    [Regexp('/[a-z]*/i')]
    [MinLength(2)]
    [MaxLength(255)]
    public $name;

    [NotNull]
    [Zipcode]
    public $zipcode;
    }
    I'm not sure I understand - why can't you use normal data structure to
    keep this information? Why it has to be in weird syntax with []s that
    has to be accessed through reflection?
    powerful frameworks which can used by a great range of developers
    without learning a new syntax for it. Pleas do not argue about thy
    syntax of the annotation because this isn't final.
    Whatever syntax it is, it is definitely new.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Christian Kaps at Sep 15, 2010 at 7:04 am

    On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev wrote:
    Hi!
    class User {

    [NotNull]
    [Integer]
    public $id;

    [NotNull]
    [Regexp('/[a-z]*/i')]
    [MinLength(2)]
    [MaxLength(255)]
    public $name;

    [NotNull]
    [Zipcode]
    public $zipcode;
    }
    I'm not sure I understand - why can't you use normal data structure
    to keep this information? Why it has to be in weird syntax with []s
    that has to be accessed through reflection?
    - Annotations are like enum fields, or a function headers. You can only
    specify these values defined by the annotation. In normal data
    structures like arrays you can define what you will.
    - The meta information is defined on top of the property to which this
    information belongs.
    - To use this information by the validator you must make this
    information public in the object model. This can be more work, or the
    informations should not be accessible through the object.
    - When I look at the code I can promptly see what validation rules are
    used for this property.
    - Metadata is a part of the property, method or class. This information
    should not be described contextless.

    There are other examples in which the information should be described
    in context of the method, class or whatever. When using dependency
    injection as example.

    class Controller {

    [Inject]
    public function setRouter(Router $router) {

    }
    }

    The dependency injection container must know the method on which the
    router should be injected into the controller. Sure this information can
    be defined anywhere in the class or a config file. But the config file
    need also parsing time. And the information is quoted out of context.

    Can you really not see the elegancy and the advantage for the users?
    powerful frameworks which can used by a great range of developers
    without learning a new syntax for it. Pleas do not argue about thy
    syntax of the annotation because this isn't final.
    Whatever syntax it is, it is definitely new.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Stas Malyshev at Sep 15, 2010 at 8:07 am
    Hi!
    - Annotations are like enum fields, or a function headers. You can only
    specify these values defined by the annotation. In normal data
    structures like arrays you can define what you will.
    This is irrelevant for PHP as it's not compiled. So the check would
    happen in runtime, how does it matter when? I'd rather prefer the check
    to happen at the time of use - this way, if I have bad annotation and
    nobody uses it, my class won't break.
    - The meta information is defined on top of the property to which this
    information belongs.
    - To use this information by the validator you must make this
    information public in the object model. This can be more work, or the
    informations should not be accessible through the object.
    I'm not sure I understand. How public is more work? And what's the
    problem with it being accessible?
    - When I look at the code I can promptly see what validation rules are
    used for this property.
    You can see it with data too, it'd be right there.
    - Metadata is a part of the property, method or class. This information
    should not be described contextless.
    Why it should be a part of the property? Property is not an entity in
    PHP anyway - you can't assign it somewhere (as property, not value) and
    get back to it later - classes, methods and properties are not
    first-class objects in PHP (unlike some other languages, yes). So I'm
    not sure I understand why having metadata as part of the property is
    important (or what it means at all).
    class Controller {

    [Inject]
    public function setRouter(Router $router) {

    }
    }

    The dependency injection container must know the method on which the
    router should be injected into the controller. Sure this information can
    You are answering the question "how current proposal is useful". It is
    not a question that I asked. I asked "why the same can't be done with
    plain data?" Showing more examples of how you can use annotations
    doesn't answer this question.
    Can you really not see the elegancy and the advantage for the users?
    Elegancy is subjective. Please understand that I'm not asking all these
    questions because I hate this proposal or the idea of annotations or you
    :) I am asking them because I think we have to have very clear
    understanding of why we doing it - especially when we are asked to
    introduce new syntax to the language which would have implications for
    the future. And "it looks nice" doesn't cut it. So far I wasn't shown
    clear case of why it's superior - that's what I am asking.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Christian Kaps at Sep 15, 2010 at 7:37 am

    On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev wrote:

    Whatever syntax it is, it is definitely new.
    Yes, but this should not be an argument against it. So every new
    feature can have new syntax or should PHP freeze on the current state!?
    I can't honestly understand why developer shouldn't understand the new
    syntax. These developers which are familiar with annotations, I think
    have no problem. This users which are new to annotations must learn the
    new syntax like any other new syntax too. Where is the problem?
  • Zeev Suraski at Sep 15, 2010 at 8:12 am

    At 09:37 15/09/2010, Christian Kaps wrote:
    On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
    wrote:
    Whatever syntax it is, it is definitely new.
    Yes, but this should not be an argument against it. So every new
    feature can have new syntax or should PHP freeze on the current state!?
    I can't honestly understand why developer shouldn't understand the new
    syntax. These developers which are familiar with annotations, I think
    have no problem. This users which are new to annotations must learn the
    new syntax like any other new syntax too. Where is the problem?
    Christian,

    Introducing large amounts of new syntax is by itself a very strong
    negative when weighing the pros and cons of a new proposed
    feature. Does it mean that 'every new feature that has new syntax'
    should not be considered? No - but it certainly means that features
    introducing new syntax, especially large amounts of it, should have
    extremely compelling advantages and cater to a very large
    audience. If there's already another way of reaching the same goal,
    even if it's not a perfect-fit but a good-enough fit, that is also a
    strong argument against the introduction of a new syntax.

    And I honestly don't think that syntax is the only issue here. It's
    the introduction of yet another new entity, another concept into the
    language. "How difficult can it be to understand?" - probably not
    very, but every new concept introduced to the language makes it a bit
    more difficult to understand, a bit less intuitive, a bit more
    complex. There won't be a flashing red light warning us when we're
    about to cross the line to making PHP 'too complicated'.

    In terms of language-level features, I don't think it's bad at all if
    PHP went into a mode that most of the other mature languages went
    into - where syntax changes or introduction of new language level
    features are pretty rare. Out of all of the mature languages out
    there, I think PHP has by far the most new syntax-introducing
    features per version, and personally I don't think that's a good
    thing. Most of the new features should come from new extensions, new
    libraries and frameworks - not syntax changes.

    Zeev
  • Pierre Joye at Sep 15, 2010 at 8:46 am

    On Wed, Sep 15, 2010 at 10:12 AM, Zeev Suraski wrote:

    In terms of language-level features, I don't think it's bad at all if PHP
    went into a mode that most of the other mature languages went into - where
    syntax changes or introduction of new language level features are pretty
    rare.  Out of all of the mature languages out there, I think PHP has by far
    the most new syntax-introducing features per version, and personally I don't
    think that's a good thing.  Most of the new features should come from new
    extensions, new libraries and frameworks - not syntax changes.
    Annotations went into the language level for other languages as well.

    However I agree about the syntax issues, but the problem is the total
    lack of clean roadmap and designs more than features additions like
    this one. The way we decided the NS separator was typically one of
    these bad choices, made in a hurry without consensus.

    It is also correct that new features should come through extension.
    But languages level features should be done at the engine level.
    Annotation support is a language level feature.

    It is also critical to understand the evolution of the languages,
    where new languages features are required to move forward. What we
    introduced (or plan to) lately are very good things, like closure or
    traits (to be committed?). And I don't see a huge difference in
    language syntax addition or core features addition between PHP and
    other languages, looking at php3 > 5+ or C# and java various features
    in the same timeline.

    The only difference in PHP is the complete lack of clear road map and
    the chaotic way of deciding things.

    I also see a kind of interest conflict of interests in your case while
    promoting (a) framework(s) instead of updating the core to match the
    current level of features of other languages.

    Cheers,
  • Christian Kaps at Sep 15, 2010 at 9:04 am

    On Wed, 15 Sep 2010 10:46:45 +0200, Pierre Joye wrote:

    The only difference in PHP is the complete lack of clear road map and
    the chaotic way of deciding things.
    Yes, I personally see here a huge problem too.
  • Stas Malyshev at Sep 15, 2010 at 6:27 pm
    Hi!
    However I agree about the syntax issues, but the problem is the total
    lack of clean roadmap and designs more than features additions like
    this one. The way we decided the NS separator was typically one of
    these bad choices, made in a hurry without consensus.
    I wouldn't call it "in a hurry" - it dragged for so long time that
    everybody pretty much felt any (re)solution would be better than
    continuing that discussion anymore.
    I agree with you that lack of roadmap and designs is a problem - that's
    exactly why I insist on not rushing in with new additions, especially
    when they introduce new concepts that are just like concepts we already
    have but with tweaks. Having such things in the language makes it a mess
    where you never know what to expect. I am especially suspicious of the
    features that have you add 20-line mishmash of unreadable pseudo-code to
    one-line language construct. This carries very heavy burden of proof. If
    you or somebody else can offer a plan where this is an integral and
    logical part of it - great, let's discuss it.
    traits (to be committed?). And I don't see a huge difference in
    language syntax addition or core features addition between PHP and
    other languages, looking at php3> 5+ or C# and java various features
    in the same timeline.
    PHP is meant for different audience than C# or Java. PHP is an
    entry-level language. If you have same learning curve for PHP as they
    have for Java, what we are doing here? Just adding $'s to variables?
    There should be a difference.
    The only difference in PHP is the complete lack of clear road map and
    the chaotic way of deciding things.
    I totally agree that we need to have that. Let's work on that. That's
    what I am trying to do - have broader view on things and not just
    discuss every cool trick in isolation.
    I also see a kind of interest conflict of interests in your case while
    promoting (a) framework(s) instead of updating the core to match the
    current level of features of other languages.
    We don't have to keep up with Joneses. If we need in PHP, fine, but
    adding feature just because Java has it makes no sense to me.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Pierre Joye at Sep 15, 2010 at 9:46 pm
    hi Stas,
    On Wed, Sep 15, 2010 at 8:27 PM, Stas Malyshev wrote:

    PHP is meant for different audience than C# or Java. PHP is an entry-level
    language. If you have same learning curve for PHP as they have for Java,
    what we are doing here? Just adding $'s to variables? There should be a
    difference.
    PHP is meant for everything as long as it is web. Users base goes from
    the kids writing their 1st web site to complex (so called) enterprise
    applications. For one, I prefer to target the 2nd while keeping PHP as
    easy as possible for the sooner. In the case of the annotation, the
    kids writing their websites won't use them, the learning curve remains
    unchanged.

    Now about the 'we are not <put whatever language you don't want to
    be>', that's irrelevant, sorry :)

    Cheers,
  • Stas Malyshev at Sep 15, 2010 at 10:00 pm
    Hi!
    easy as possible for the sooner. In the case of the annotation, the
    kids writing their websites won't use them, the learning curve remains
    unchanged.
    No, because they look at the framework code and when they see all this
    {[@#!Blah($%@Blah=Blah$^)]} they'd have hard time figuring out what that
    means - unless we make it easy. I understood that common consensus was
    even [1,2,3] is not easy enough - has that changed?
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Gustavo Lopes at Sep 15, 2010 at 10:34 pm

    On Wed, 15 Sep 2010 23:00:15 +0100, Stas Malyshev wrote:

    easy as possible for the sooner. In the case of the annotation, the
    kids writing their websites won't use them, the learning curve remains
    unchanged.
    No, because they look at the framework code and when they see all this
    {[@#!Blah($%@Blah=Blah$^)]} they'd have hard time figuring out what that
    means - unless we make it easy. I understood that common consensus was
    even [1,2,3] is not easy enough - has that changed?
    They won't look at framework code; they'll look at some random tutorial
    about PHP+MySQL and write a program full of vulnerabilities :p
    Do you really think they'll go see the source code for Symphony?... They
    won't understand it as it is now.

    Anyway, this is not even remotely comparable to [1,2,3]. One is mere
    syntactic sugar (albeit easier on the keyboard and arguably more readable)
    that solves the same problem as a construct we already have, the other is
    actually new functionality, which happens to require new syntax.

    I agree that a language should be beginner-friendly; after all, beginners
    will always be the majority of the users for any live language.

    But can't we have a language that's easy to learn (you can start writing
    programs in it very quickly), yet powerful, i.e., expressive? Annotations
    are very expressive (please don't say "there are no use cases"); they have
    a wide range of applications, from simplifying configuration to making
    aspect oriented programming much cleaner.

    From my experience when I first learned about annotations, the concept is
    very easy to apprehend. What's difficult is to understand what they can be
    useful for.

    They can also be a bit dangerous because they may hide the code that's
    actually being run. Whether that will be a problem or not, only the future
    will tell. Still, I don't think it will be nearly as dangerous as global
    variables or variable variables (or as other stuff we don't have, like
    operator overloading).

    --
    Gustavo Lopes
  • Alec at Sep 16, 2010 at 1:16 am
    Gustavo's message pretty much expresses exactly how I feel.

    As an extension, I feel that as long as annotations don't slow down
    existing non-annotated code (or code using the ridiculous phpdoc
    parsing), then I see no reason to keep annotations from being added.

    People argue that the new syntax is bad and confusing to beginners. As
    someone who did their first programming in any language in 2006 in PHP,
    OOP confused the heck out of me. I knew the pros used it, but also knew
    I wasn't a pro. So I ignored it. I didn't say how crazy PHP is for
    having these wild things called "classes" that I didn't understand. As I
    became more experienced with PHP, I started to understand classes. Then
    I figured out that classes *are* useful, so I started using them.

    Also, for the record, I didn't even know what a PHP framework was when I
    started PHP, and even when I found out, I never thought that looking
    through it might be the best way to learn something (this is different
    now of course, but I am a much more experienced developer presently).

    I think the most troublesome thing from my point of view is the fact
    that it makes PHP just that much more complicated. However, I don't
    think this is a huge issue because annotations are fairly simple, yet
    quite powerful.

    On an unrelated note, I really wish the [] syntax for arrays was put in,
    because:
    1. It is easier to type. (subjective)
    2. It is easier to read. (subjective)
    3. When developing a web app, having the similar syntax is nice.
    4. I never understood the argument that they would be unclear.
    Javascript does it the [] (and they still have the new Array() method too).

    However, that is all behind us (unfortunately, I missed that arugment :( )

    I hope annotations make the cut for whatever the next release of PHP is.
    On 9/15/2010 6:34 PM, Gustavo Lopes wrote:
    On Wed, 15 Sep 2010 23:00:15 +0100, Stas Malyshev
    wrote:
    easy as possible for the sooner. In the case of the annotation, the
    kids writing their websites won't use them, the learning curve remains
    unchanged.
    No, because they look at the framework code and when they see all this
    {[@#!Blah($%@Blah=Blah$^)]} they'd have hard time figuring out what
    that means - unless we make it easy. I understood that common
    consensus was even [1,2,3] is not easy enough - has that changed?
    They won't look at framework code; they'll look at some random tutorial
    about PHP+MySQL and write a program full of vulnerabilities :p
    Do you really think they'll go see the source code for Symphony?... They
    won't understand it as it is now.

    Anyway, this is not even remotely comparable to [1,2,3]. One is mere
    syntactic sugar (albeit easier on the keyboard and arguably more
    readable) that solves the same problem as a construct we already have,
    the other is actually new functionality, which happens to require new
    syntax.

    I agree that a language should be beginner-friendly; after all,
    beginners will always be the majority of the users for any live language.

    But can't we have a language that's easy to learn (you can start writing
    programs in it very quickly), yet powerful, i.e., expressive?
    Annotations are very expressive (please don't say "there are no use
    cases"); they have a wide range of applications, from simplifying
    configuration to making aspect oriented programming much cleaner.

    From my experience when I first learned about annotations, the concept
    is very easy to apprehend. What's difficult is to understand what they
    can be useful for.

    They can also be a bit dangerous because they may hide the code that's
    actually being run. Whether that will be a problem or not, only the
    future will tell. Still, I don't think it will be nearly as dangerous as
    global variables or variable variables (or as other stuff we don't have,
    like operator overloading).
  • Christian Kaps at Sep 15, 2010 at 8:50 am

    On Wed, 15 Sep 2010 10:12:43 +0200, Zeev Suraski wrote:
    At 09:37 15/09/2010, Christian Kaps wrote:
    On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
    wrote:
    Whatever syntax it is, it is definitely new.
    Yes, but this should not be an argument against it. So every new
    feature can have new syntax or should PHP freeze on the current state!?
    I can't honestly understand why developer shouldn't understand the new
    syntax. These developers which are familiar with annotations, I think
    have no problem. This users which are new to annotations must learn the
    new syntax like any other new syntax too. Where is the problem?
    Christian,

    Introducing large amounts of new syntax is by itself a very strong
    negative when weighing the pros and cons of a new proposed feature.
    Does it mean that 'every new feature that has new syntax' should not
    be considered? No - but it certainly means that features introducing
    new syntax, especially large amounts of it, should have extremely
    compelling advantages and cater to a very large audience. If there's
    already another way of reaching the same goal, even if it's not a
    perfect-fit but a good-enough fit, that is also a strong argument
    against the introduction of a new syntax.

    And I honestly don't think that syntax is the only issue here. It's
    the introduction of yet another new entity, another concept into the
    language. "How difficult can it be to understand?" - probably not
    very, but every new concept introduced to the language makes it a bit
    more difficult to understand, a bit less intuitive, a bit more
    complex. There won't be a flashing red light warning us when we're
    about to cross the line to making PHP 'too complicated'.

    In terms of language-level features, I don't think it's bad at all if
    PHP went into a mode that most of the other mature languages went into
    - where syntax changes or introduction of new language level features
    are pretty rare. Out of all of the mature languages out there, I
    think PHP has by far the most new syntax-introducing features per
    version, and personally I don't think that's a good thing. Most of
    the new features should come from new extensions, new libraries and
    frameworks - not syntax changes.

    Zeev
    Zeev and Stas,

    I can understand your mind and I can only repeat again that in my
    opinion annotations are a great feature which can help to produce better
    software in a simpler way. And I think I am not alone.

    My last question is, if it makes sense to argue more or is the decision
    already been made against annotations. Because personally, I have no
    arguments anymore for implementing annotations in PHP.

    Greetings,
    Christian
  • Matthew Weier O'Phinney at Sep 16, 2010 at 6:01 pm

    On 2010-09-15, Christian Kaps wrote:
    Am 14.09.2010 22:12, schrieb Stas Malyshev:
    I think we _already_ have metadata in PHP, albeit done through
    phpdocs. So the question is kind of moot :) We should see if it's
    enough for us or we want to add/change/extend it and if so, how.
    in my mind there is a big mistake when using annotations in PHPDoc comments.
    What is the mistake? You don't explain that anywhere in your reply -- you simply
    give code examples of how you feel they should work.
    As example let as use a JSR 303 - Bean Validator like Hibernate
    Validator for PHP.

    namespace my\project\models\dto;

    class User {

    /**
    * @com\jsr303\validator\constraints\NotNull
    * @com\jsr303\validator\constraints\Integer
    */
    public $id; <snip>
    It is possible to use this type of annotations but it is impracticable.
    How is it impractical? What exactly is impractical about it? To be honest, what
    you show above (and also in your more "ideal" examples below) leaves me
    scratching my head -- if the classnames don't have the word "validator" in them,
    I have _zero_ idea what the intent of the annotation is.
    An other problem is that every framework use its one annotation syntax.
    So it makes the framework end user more confusing as using a clear
    unique syntax.
    Actually, I see this as a _benefit_ or _feature_ of such an approach -- it
    allows developers to define their own annotations, which allows them to create
    new approaches. We see this already in docblock annotations -- PHPUnit makes use
    of them (@expectedException, @group, etc.). Groups like the Framework Interop
    Group can tackle standard use cases.

    I think the PHP way should be as in the next example.

    namespace my\project\models\dto;

    use com\jsr303\validator\constraints\NotNull;
    use com\jsr303\validator\constraints\Integer;
    use com\jsr303\validator\constraints\Regexp;
    use com\jsr303\validator\constraints\MinLength;
    use com\jsr303\validator\constraints\MaxLength;
    use my\project\validator\constraints\Zipcode;

    class User {

    [NotNull]
    [Integer]
    public $id;
    This is entirely unclear to me. Will it type-cast to integers? will it throw an
    exception for null values? I actually don't know what this code will do -- which
    brings me to my chief issue so far with this debate: annotations, since they are
    meant to be "machine-readable" (that's what all the proponents are saying,
    anyways), introduce a huge WTF factor when debugging -- is it the code that
    caused an exception? If not, was it an annotation? Which one? what input did it
    get? etc.

    <snip>
    With this out of the box PHP annotations it makes it possible to create
    powerful frameworks which can used by a great range of developers
    without learning a new syntax for it. Pleas do not argue about thy
    syntax of the annotation because this isn't final.
    Um, you're being contradictory here -- you're actually _suggesting_ a brand new
    syntax, which leads to the exact opposite of what you assert. Using existing
    docblocks and adding an annotations parser to it would be using existing syntax.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Christian Kaps at Sep 16, 2010 at 7:02 pm

    Am 16.09.2010 18:02, schrieb Matthew Weier O'Phinney:
    in my mind there is a big mistake when using annotations in PHPDoc comments.
    What is the mistake? You don't explain that anywhere in your reply -- you simply
    give code examples of how you feel they should work.
    For me the mistake is that annotation classes must be defined with their
    FQN or you must create an alias for the namespace. This alias must be
    registered before using this annotations. Every framework I use uses its
    own rules for defining annotatations, registering annotation namespaces
    and so on. For me this is impractical. Registering the namespace with
    the out of the box PHP use statement is for me the better way.

    I thought this was clear from my comparison.
    An other problem is that every framework use its one annotation syntax.
    So it makes the framework end user more confusing as using a clear
    unique syntax.
    Actually, I see this as a _benefit_ or _feature_ of such an approach -- itwer ist den dir auf den schlips getreten
    allows developers to define their own annotations, which allows them to create
    new approaches. We see this already in docblock annotations -- PHPUnit makes use
    of them (@expectedException, @group, etc.). Groups like the Framework Interop
    Group can tackle standard use cases.
    This isn't what I meant with different syntax. Different syntax for me is:

    [Annotation([1, 2, 3])]
    @Annotation({1, 2, 3})
    %Annotation(array(1, 2, 3))

    Have fun, using annotations from different frameworks for one and the
    same method, property or class.
    I think the PHP way should be as in the next example.

    namespace my\project\models\dto;

    use com\jsr303\validator\constraints\NotNull;
    use com\jsr303\validator\constraints\Integer;
    use com\jsr303\validator\constraints\Regexp;
    use com\jsr303\validator\constraints\MinLength;
    use com\jsr303\validator\constraints\MaxLength;
    use my\project\validator\constraints\Zipcode;

    class User {

    [NotNull]
    [Integer]
    public $id;
    This is entirely unclear to me. Will it type-cast to integers? will it throw an
    exception for null values? I actually don't know what this code will do -- which
    brings me to my chief issue so far with this debate: annotations, since they are
    meant to be "machine-readable" (that's what all the proponents are saying,
    anyways), introduce a huge WTF factor when debugging -- is it the code that
    caused an exception? If not, was it an annotation? Which one? what input did it
    get? etc.
    If an annotation throws an exception because of syntax errors you get an
    stack trace. So it should not be a problem to localize this error.
    In this example the annotations doesn't throw any exceptions.

    $user = new User;
    $user->id = 'only integers are allowed';

    $validator = new Validator();
    $results = $validator->validate($user);

    The result contains a constraint violation message. For more you can
    look at the Hibernate Validator page.
    http://www.hibernate.org/subprojects/validator.html
    With this out of the box PHP annotations it makes it possible to create
    powerful frameworks which can used by a great range of developers
    without learning a new syntax for it. Pleas do not argue about thy
    syntax of the annotation because this isn't final.
    Um, you're being contradictory here -- you're actually _suggesting_ a brand new
    syntax, which leads to the exact opposite of what you assert.
    I meant that this developers who using this frameworks must not learn
    different syntaxes but rather one.
    Using existing
    docblocks and adding an annotations parser to it would be using existing syntax.
    - How would you comment out an annotation in a doc block?
    - How would you define annotations with namespaces?
    - Parsing of annotations is slow. When using caching every framework
    that I use implements other caching rules for its annotations.

    There are many more reasons mentioned in all the mails.


    You may excuse me because I am not an native English speaker so it can
    be be the case the one or the other formulation isn't correct.

    Greetings,
    Christian
  • Ferenc Kovacs at Sep 14, 2010 at 6:49 pm

    On Tue, Sep 14, 2010 at 7:25 PM, Nate Abele wrote:
    At 17:51 13/09/2010, Gustavo Lopes wrote:
    On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
    At 16:39 13/09/2010, Pierre Joye wrote:
    You are not serioulsy suggesting to use phpdoc for runtime
    annotation
    support? Are you?
    I actually am (either that or get what you want done in some other
    way). It's a rare enough use case that I think it's a very
    reasonable
    compromise. The disadvantages of adding a whole new branch of
    syntax,
    for this rare use case, far outweigh its advantages - IMHO.
    Rare use case? Have you seen any recent Java framework? Or Java EE 6?
    Or
    design by contract in C#? A declarative programming style can be very
    handy.
    Framework code (as in code that actually goes into a framework, not
    code
    that uses a framework) represents a tiny percentage of the PHP codebase
    at large. Most of it is application code.

    You misunderstood me. When I say the frameworks use annotation I don't
    mean they use annotations in their own implementation (that's not
    particularly relevant for the reason you present).

    What I mean is that the frameworks recognize annotations the application
    code has so that the framework user can do stuff like injecting objects,
    run methods in transactions or check post-conditions in a declarative
    fashion, by adding annotations.

    By the way, you ignored the rest of the e-mail.

    How do you evaluate the complexity/return of features such as annotations
    with that of e.g. LSB? Why are they not adequate for PHP, but may be for
    other languages?
    I do not understand this.

    I see no one other than Symfony / Doctrine people pushing for this
    annotations patch.

    How can this special-purpose feature (which would add entirely new language
    semantics in the form of an embedded micro-language) even be open for
    discussion, when other, more generally-useful RFCs like
    http://wiki.php.net/rfc/shortsyntaxforarrays were shot down on the basis
    that they were hard to read and confusing for new developers?

    Sorry, but I don't see how this is even remotely close to being appropriate
    for PHP. Maybe I'm missing something. :-)

    Thanks,
    - Nate
    It's the same as Zeev said:

    "The fact we have complex components in PHP is no excuse to add more
    complexity to the language. It's not a binary state, with PHP "already
    being complex", so we can add as much complexity as we want. Complexity
    accumulates."
    The fact that we rejecteded better features in PHP is no excuse to reject
    good ideas from the...

    at least without a discussion which is just happening.

    Tyrael

Related Discussions

People

Translate

site design / logo © 2018 Grokbase