# PHP 5.4 - Meta attribute (aka. Annotations) support discussion - Thread: https://externals.io/message/50206 - Original archive: https://news-web.php.net/php.internals/50206 - Started by guilhermeblanco@gmail.com on 2010-11-15T17:07:34+00:00 - Messages: 73 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/50206.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #50206 — guilhermeblanco@gmail.com — 2010-11-15T17:07:34+00:00 URL: https://externals.io/message/50206#50206 Hi folks, I'll start a series of topics (in this thread) about meta attribute (aka. Annotations) discussion. So as soon as we agree on each topic I'll open another point to be discussed. Only when we reach some consensus I'll open another topic discussion. I suggest to have a poll for each topic, so we can do some democratic internals decision. I'd reduce the scope of voters to only people with PHP karma. The first topic to be defined is: Does PHP need meta attribute support? Any language is built at the top of syntax, words, semantics and context. We cannot define it as a language if we don't have these 4 parts well fit together. For a simple sentence like: I am all ears, we can easily identify these parts. But the real meaning of this sentence (context) is only achieved with another part of the language: signifier-significate. A signifier is an atomic form, material element, visible, sensitive. A significate is an idea, semantic content, conceptual element, not sensitive perceptive. This important part is only reminded when we get back to semantics, specifically when talking about idiomatic expressions, a metaphor in our sample. The meaning will only work if we have the context, a known information. Our sentence would mean that spoker person only have ears, while the true meaning is that he/she is paying attention. A computer language doesn't differ from a language by any means. We have tokens (words), a syntax, semantic. But the lack of contextualization brings a hole on language and how your application should behave. This behavior can be achieved by many different ways; the simplest way is known as meta information. Considering you have a lack of idiomatic expressions knowledge of someone that is reading. He'd think person only have ears, but if you meta notify him that it is a metaphor, he'd try to find a different meaning. Example: (Metaphor) I am all ears. Now that we find how meta-information can benefit languages, it is time to understand how meta-information can benefit a computer language. A good example is define a Service that validates Domain Objects. Imagining a scenario where you have a User class that holds email and password. Email and password fields must be validated, for example, email as an email and password with at least 6 chars. A generic validation service could not have the User validation hardcoded inside the service, so the solution would be an external factor that explains to service how to validate the DO. One of the possible implementations would be a UserValidator class that contains validation rules for each field. This external factor is a good sample of meta-information. But how would a meta attribute would solve this situation? A Service could simple retrieve the validation instructions by Reflecting the class which instance is going to be validated. Basically, to validate a Domain Object, it is simply required to add validation rules on desired attributes. Example: class User { protected $email; protected $password; } *NOTE*: Please understand that this do not enter in any implementation details. It is not time (yet) to talk baout docblock, new syntax, etc. Scope now is simpler than that. Now that is possible to see how meta attribute support could benefit a language, I compiled a simple list of known projects and how can they benefit of meta support: - phpUnit Providing meta functionality for test cases, examples: @dataProvider for test data iteration, @expectedException for catching exceptions, etc. - Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, @Id, etc. - Zend Framework Server classes Used to automate mappings for XML-RPC, SOAP, etc. - FLOW3 for dependency injection and validation - Symfony2 for validation and routing rules - Others: Validation, Functional Behavior injection (which could take advantage of Traits), etc. Poll will be opened for voting for 7 days (1 week) starting from now. Poll will be closed next Monday at 5pm GMT. Question: Does PHP need meta attribute support? Happy voting! -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #50208 — Zeev Suraski — 2010-11-15T22:22:13+00:00 URL: https://externals.io/message/50206#50208 · In reply to: #50206 I don't see a point in repeating the discussion we've already had on that topic several weeks ago. There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't. Zeev > -----Original Message----- > From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com] > Sent: Monday, November 15, 2010 7:08 PM > To: PHP internals > Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support > discussion > > Hi folks, > > I'll start a series of topics (in this thread) about meta attribute (aka. > Annotations) discussion. > So as soon as we agree on each topic I'll open another point to be discussed. > Only when we reach some consensus I'll open another topic discussion. > I suggest to have a poll for each topic, so we can do some democratic > internals decision. I'd reduce the scope of voters to only people with PHP > karma. > > The first topic to be defined is: Does PHP need meta attribute support? > > Any language is built at the top of syntax, words, semantics and context. > We cannot define it as a language if we don't have these 4 parts well fit > together. > For a simple sentence like: I am all ears, we can easily identify these parts. > But the real meaning of this sentence (context) is only achieved with another > part of the language: signifier-significate. > A signifier is an atomic form, material element, visible, sensitive. > A significate is an idea, semantic content, conceptual element, not sensitive > perceptive. > > This important part is only reminded when we get back to semantics, > specifically when talking about idiomatic expressions, a metaphor in our > sample. The meaning will only work if we have the context, a known > information. Our sentence would mean that spoker person only have ears, > while the true meaning is that he/she is paying attention. > A computer language doesn't differ from a language by any means. We have > tokens (words), a syntax, semantic. But the lack of contextualization brings a > hole on language and how your application should behave. This behavior can > be achieved by many different ways; the simplest way is known as meta > information. > > Considering you have a lack of idiomatic expressions knowledge of someone > that is reading. He'd think person only have ears, but if you meta notify him > that it is a metaphor, he'd try to find a different meaning. Example: > (Metaphor) I am all ears. > > Now that we find how meta-information can benefit languages, it is time to > understand how meta-information can benefit a computer language. > > A good example is define a Service that validates Domain Objects. > Imagining a scenario where you have a User class that holds email and > password. Email and password fields must be validated, for example, email > as an email and password with at least 6 chars. A generic validation service > could not have the User validation hardcoded inside the service, so the > solution would be an external factor that explains to service how to validate > the DO. One of the possible implementations would be a UserValidator class > that contains validation rules for each field. This external factor is a good > sample of meta-information. But how would a meta attribute would solve > this situation? > A Service could simple retrieve the validation instructions by Reflecting the > class which instance is going to be validated. > Basically, to validate a Domain Object, it is simply required to add validation > rules on desired attributes. Example: > > class User { > > protected $email; > > > protected $password; > } > > *NOTE*: Please understand that this do not enter in any implementation > details. It is not time (yet) to talk baout docblock, new syntax, etc. > Scope now is simpler than that. > > Now that is possible to see how meta attribute support could benefit a > language, I compiled a simple list of known projects and how can they > benefit of meta support: > - phpUnit Providing meta functionality for test cases, examples: > @dataProvider for test data iteration, @expectedException for catching > exceptions, etc. > - Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, > @Id, etc. > - Zend Framework Server classes Used to automate mappings for XML-RPC, > SOAP, etc. > - FLOW3 for dependency injection and validation > - Symfony2 for validation and routing rules > - Others: Validation, Functional Behavior injection (which could take > advantage of Traits), etc. > > > Poll will be opened for voting for 7 days (1 week) starting from now. > Poll will be closed next Monday at 5pm GMT. > Question: Does PHP need meta attribute support? > > Happy voting! > > -- > Guilherme Blanco > Mobile: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #50209 — Pierre Joye — 2010-11-15T22:42:55+00:00 URL: https://externals.io/message/50206#50209 · In reply to: #50208 hi, The good reason is to actually understand what we are talking about. And seeing phpdoc mentioned in almost all replies tell me that we don't. > I don't see a point in repeating the discussion we've already had on that topic several weeks ago.  There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't. > > Zeev > > > […] > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50210 — Zeev Suraski — 2010-11-15T23:39:56+00:00 URL: https://externals.io/message/50206#50210 · In reply to: #50209 Suggesting phpdoc is used for the purposes mentioned does not mean we don't understand what we're talking about. Zeev > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Tuesday, November 16, 2010 12:43 AM > To: Zeev Suraski > Cc: guilhermeblanco@gmail.com; PHP internals > Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support > discussion > > hi, > > The good reason is to actually understand what we are talking about. > And seeing phpdoc mentioned in almost all replies tell me that we don't. > > > > […] > topic several weeks ago.  There needs to be an overwhelmingly good reason > to add a brand new syntax to the language, a whole branch of it in the case of > annotations - and there simply isn't. > > […] > discussed. > > […] > Example: > > […] > language. > > […] > this situation? > > […] > syntax, etc. > > […] > visit: > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50211 — Pierre Joye — 2010-11-15T23:44:42+00:00 URL: https://externals.io/message/50206#50211 · In reply to: #50210 > Suggesting phpdoc is used for the purposes mentioned does not mean we don't understand what we're talking about. I feel like you never used annotations in other languages, did you? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50212 — Will Fitch — 2010-11-15T23:54:54+00:00 URL: https://externals.io/message/50206#50212 · In reply to: #50211 I have certainly wanted them many times - especially when using SOAP. Having WSDL auto-generation without compromising developer documentation and attempting to have user-land code parse phpdoc for this purpose seem{ed,s} counterintuitive. That said, introducing annotations is a HUGE undertaking and would require a ton of work with potentially little return. I do think it would be worth looking into in a future major release, but there are quite a few other things that would be more beneficial to the community for immediate discussions. Did anyone write and RFC on this? guilhermeblanco has a good start. > > > […] > don't understand what we're talking about. > > I feel like you never used annotations in other languages, did you? > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fitch@quepasacorp.com Twitter: twitter.com/willfitch --- ## #50213 — Alec — 2010-11-16T00:47:01+00:00 URL: https://externals.io/message/50206#50213 · In reply to: #50212 The patch is already written and a RFC created by Guilherme: http://wiki.php.net/rfc/annotations . I personally think annotations could make a *great* addition to PHP. I agree with Will that annotations are especially useful for SOAP and XML-RPC. I personally think annotations are useful for APIs in general. Instead of creating a method to respond to a XML-RPC call, then binding it to a specific XML-RPC call with a line in the initialization you could just do this: @xmlrpc({ name : "server.getValue", params : { param1 : { type : "number", docs : "This is documentation for param1" } } }); public getValForXMLRPC ($param) { ... I just used JSON for the syntax of annotation. I did this for two reasons: 1. most PHP developers can write some Javascript, and 2. since this is supposed to avoid syntax discussions, I used a syntax no one uses for annotations, but everyone understands. The possibilities are endless with Annotations and as long as they are pretty speedy I think they would be picked up quite quickly and we would get some great examples from the community. My 2 cents. -Alec > I have certainly wanted them many times - especially when using SOAP. > Having WSDL auto-generation without compromising developer > documentation and attempting to have user-land code parse phpdoc for this > purpose seem{ed,s} counterintuitive. That said, introducing annotations is > a HUGE undertaking and would require a ton of work with potentially little > return. I do think it would be worth looking into in a future major > release, but there are quite a few other things that would be more > beneficial to the community for immediate discussions. > > Did anyone write and RFC on this? guilhermeblanco has a good start. > > > > > […] --- ## #50214 — Will Fitch — 2010-11-16T00:55:44+00:00 URL: https://externals.io/message/50206#50214 · In reply to: #50213 Wow. I should actually look at the RFCs more frequently. I have to say, assuming the patch is valid for PHP 5.3 (which I have no doubt it is), I don't see why this can't be taken more seriously. I know the discussion was brought up a few weeks ago, but what are the objections to injecting this functionality into the next major post-5.4 release? > The patch is already written and a RFC created by Guilherme: > http://wiki.php.net/rfc/annotations . > > I personally think annotations could make a *great* addition to PHP. > > I agree with Will that annotations are especially useful for SOAP and > XML-RPC. I personally think annotations are useful for APIs in general. > > Instead of creating a method to respond to a XML-RPC call, then binding it > to a specific XML-RPC call with a line in the initialization you could just > do this: > > @xmlrpc({ > name : "server.getValue", > params : { > param1 : { > type : "number", > docs : "This is documentation for param1" > } > } > }); > public getValForXMLRPC ($param) { > ... > > I just used JSON for the syntax of annotation. I did this for two reasons: > 1. most PHP developers can write some Javascript, and 2. since this is > supposed to avoid syntax discussions, I used a syntax no one uses for > annotations, but everyone understands. > > The possibilities are endless with Annotations and as long as they are > pretty speedy I think they would be picked up quite quickly and we would get > some great examples from the community. > > My 2 cents. > > -Alec > > > > > > […] > > -- > > > > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fitch@quepasacorp.com Twitter: twitter.com/willfitch --- ## #50215 — Alec — 2010-11-16T01:17:15+00:00 URL: https://externals.io/message/50206#50215 · In reply to: #50214 Mostly it is that a new syntax will confuse people and add complexity that PHP doesn't need. The same people don't believe that annotations bring value worthy of adding a new syntax. Short array notation and similar are noted as precedence. That is a bulk of the arguments, but if I have forgotten any please state them. -Alec > Wow. I should actually look at the RFCs more frequently. > > I have to say, assuming the patch is valid for PHP 5.3 (which I have no > doubt it is), I don't see why this can't be taken more seriously. I know > the discussion was brought up a few weeks ago, but what are the objections > to injecting this functionality into the next major post-5.4 release? > > > > > […] --- ## #50216 — guilhermeblanco@gmail.com — 2010-11-16T02:27:55+00:00 URL: https://externals.io/message/50206#50216 · In reply to: #50208 @Zeev: That topic was related to an already built patch, which some where in favor, some against. That discussion lead to nowhere. So I opened a thread topic by topic for some democracy approval. As soon as we reach some reasonable consensus, we can start another patch implementation based on what we end up with this thread. If result of the poll says "OK" to meta attribute, then we can discuss next topic (possible implementations). Until then, I'd rather appreciate everyone to stick to their votes instead of revamp another discussion that lead to nothing. BTW, I forgot to add my vote: +1 > I don't see a point in repeating the discussion we've already had on that topic several weeks ago.  There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't. > > Zeev > > > […] > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #50217 — guilhermeblanco@gmail.com — 2010-11-16T02:29:29+00:00 URL: https://externals.io/message/50206#50217 · In reply to: #50214 @Will: Patch works perfectly with PHP 5.3. There is just a minor issue related to APC not caching instances. That patch didn't reach a consensus and that's why I opened a different thread to implement a patch based on poll results. Cheers, > Wow. I should actually look at the RFCs more frequently. > > I have to say, assuming the patch is valid for PHP 5.3 (which I have no > doubt it is), I don't see why this can't be taken more seriously.  I know > the discussion was brought up a few weeks ago, but what are the objections > to injecting this functionality into the next major post-5.4 release? > > > > > […] > > > -- > > Thanks, > > Will Fitch > Director of Operations | Quepasa.com > 931.205.8242 | will.fitch@quepasacorp.com > Twitter: twitter.com/willfitch > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #50218 — Alec — 2010-11-16T02:36:31+00:00 URL: https://externals.io/message/50206#50218 · In reply to: #50216 I forgot my vote too: +1 > @Zeev: That topic was related to an already built patch, which some > where in favor, some against. That discussion lead to nowhere. > So I opened a thread topic by topic for some democracy approval. As > soon as we reach some reasonable consensus, we can start another patch > implementation based on what we end up with this thread. > > If result of the poll says "OK" to meta attribute, then we can discuss > next topic (possible implementations). > Until then, I'd rather appreciate everyone to stick to their votes > instead of revamp another discussion that lead to nothing. > > BTW, I forgot to add my vote: > > +1 > > > > […] --- ## #50219 — Will Fitch — 2010-11-16T02:42:58+00:00 URL: https://externals.io/message/50206#50219 · In reply to: #50218 +1 here. I'd love to see the conversation of implementation. > I forgot my vote too: +1 > > > > > > […] > > -- > > > > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fitch@quepasacorp.com Twitter: twitter.com/willfitch --- ## #50220 — Pierrick Charron — 2010-11-16T02:43:14+00:00 URL: https://externals.io/message/50206#50220 · In reply to: #50216 +1 On 15 November 2010 21:27, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > @Zeev: That topic was related to an already built patch, which some > where in favor, some against. That discussion lead to nowhere. > So I opened a thread topic by topic for some democracy approval. As > soon as we reach some reasonable consensus, we can start another patch > implementation based on what we end up with this thread. > > If result of the poll says "OK" to meta attribute, then we can discuss > next topic (possible implementations). > Until then, I'd rather appreciate everyone to stick to their votes > instead of revamp another discussion that lead to nothing. > > BTW, I forgot to add my vote: > > +1 > > > > […] > topic several weeks ago. There needs to be an overwhelmingly good reason to > add a brand new syntax to the language, a whole branch of it in the case of > annotations - and there simply isn't. > > […] > (aka. > > […] > discussed. > > […] > PHP > > […] > context. > > […] > fit > > […] > parts. > > […] > another > > […] > sensitive > > […] > brings a > > […] > can > > […] > someone > > […] > notify him > > […] > to > > […] > email > > […] > service > > […] > validate > > […] > class > > […] > good > > […] > Reflecting the > > […] > validation > > […] > visit: > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #50221 — Will Fitch — 2010-11-16T02:46:16+00:00 URL: https://externals.io/message/50206#50221 · In reply to: #50220 In conjunction to my vote, I really think Pierrick's proposal and patch is worth another look if we talk implementation. On Mon, Nov 15, 2010 at 8:43 PM, Pierrick Charron wrote: > +1 > > On 15 November 2010 21:27, guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > […] > that > > […] > to > > […] > of > > […] > support? > > […] > these > > […] > our > > […] > ears, > > […] > have > > […] > time > > […] > the > > […] > a > > […] > @OneToOne, > > […] > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fitch@quepasacorp.com Twitter: twitter.com/willfitch --- ## #50223 — Kalle Sommer Nielsen — 2010-11-16T03:39:07+00:00 URL: https://externals.io/message/50206#50223 · In reply to: #50220 2010/11/16 Pierrick Charron : > +1 +1 for annotations in 5.4 -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #50232 — Zeev Suraski — 2010-11-16T07:06:27+00:00 URL: https://externals.io/message/50206#50232 · In reply to: #50211 > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Tuesday, November 16, 2010 1:45 AM > To: Zeev Suraski > Cc: guilhermeblanco@gmail.com; PHP internals > Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support > discussion > > > > […] > don't understand what we're talking about. > > I feel like you never used annotations in other languages, did you? You got me... But as an intelligent human being I'd like to think I can evaluate the merits of a feature without having to actually use it. I'm not saying that annotations don't give you any value. Sure they do. I'm saying that they come at a great price of adding an obscure branch of syntax into a language that's already grown significantly in complexity, and the bang for the buck isn't worth it. Those advanced developers needing that feature can make do with phpdoc. Zeev --- ## #50233 — Zeev Suraski — 2010-11-16T07:10:52+00:00 URL: https://externals.io/message/50206#50233 · In reply to: #50216 I hope I won't stir the pot too much, but with all due respect to the vote of at-best a two digit subset of an arbitrary 3000+ subscribers to internals, there's an overwhelming majority amongst the principal developers of PHP that voiced an opinion against it. While we have no official rules or structures for voting features into PHP, PHP being a meritocracy, that should be enough to put this RFC to bed. Zeev > -----Original Message----- > From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com] > Sent: Tuesday, November 16, 2010 4:28 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support > discussion > > @Zeev: That topic was related to an already built patch, which some where in > favor, some against. That discussion lead to nowhere. > So I opened a thread topic by topic for some democracy approval. As soon as > we reach some reasonable consensus, we can start another patch > implementation based on what we end up with this thread. > > If result of the poll says "OK" to meta attribute, then we can discuss next > topic (possible implementations). > Until then, I'd rather appreciate everyone to stick to their votes instead of > revamp another discussion that lead to nothing. > > BTW, I forgot to add my vote: > > +1 > > > > […] > topic several weeks ago.  There needs to be an overwhelmingly good reason > to add a brand new syntax to the language, a whole branch of it in the case of > annotations - and there simply isn't. > > […] > discussed. > > […] > Example: > > […] > language. > > […] > this situation? > > […] > syntax, etc. > > […] > visit: > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #50234 — Ferenc Kovacs — 2010-11-16T07:14:25+00:00 URL: https://externals.io/message/50206#50234 · In reply to: #50232 > > […] > support > > […] > > You got me... But as an intelligent human being I'd like to think I can > evaluate the merits of a feature without having to actually use it. > > I'm not saying that annotations don't give you any value. Sure they do. > I'm saying that they come at a great price of adding an obscure branch of > syntax into a language that's already grown significantly in complexity, and > the bang for the buck isn't worth it. Those advanced developers needing > that feature can make do with phpdoc. > > Zeev > > -- > > > > it can't see your point. if the current phpdoc would be enough, then they wouldn't propose the annotation. if you can't do everything with phpdoc that you could do with annotation, then I can see 2 choice: - forget the advanced stuff, but in this case, don try to sound as the phpdoc would be an alternative - extend the phpdoc support to cover the missing parts: how would that less obscure? phpdoc isn't up for the task. if you did read the RFC and did your research about the annotations, then you know that. Tyrael --- ## #50235 — Zeev Suraski — 2010-11-16T07:21:18+00:00 URL: https://externals.io/message/50206#50235 · In reply to: #50234 If past experience is any indicator then you’re hardly correct regarding your first statement – being able to do something in PHP was no insurance against proposals suggesting new ways of doing the same thing – often in an improved way. Re: the 2nd part, extending phpdoc would be way less obscure because we’d be building on existing, already defined and widely used syntax. To make it clear – I’m not suggesting we add all of the complexity of the annotations proposal on top of phpdoc, but something fairly minimal. That’s why I said developers should ‘make do’ with phpdoc (with slight improvements around storing doc blocks where we don’t store them today). Like I said – of course annotations bring value. If that was the only property when evaluating a new feature to be added, PHP would very quickly become an everything-and-the-kitchen-sink language. Thankfully, it’s not. Zeev it can't see your point. if the current phpdoc would be enough, then they wouldn't propose the annotation. if you can't do everything with phpdoc that you could do with annotation, then I can see 2 choice: - forget the advanced stuff, but in this case, don try to sound as the phpdoc would be an alternative - extend the phpdoc support to cover the missing parts: how would that less obscure? phpdoc isn't up for the task. if you did read the RFC and did your research about the annotations, then you know that. Tyrael --- ## #50236 — Lester Caine — 2010-11-16T07:38:32+00:00 URL: https://externals.io/message/50206#50236 · In reply to: #50233 ( Try again Zeev changing the pigging address ;) ) Zeev Suraski wrote: > I hope I won't stir the pot too much, but with all due respect to the vote of at-best a two digit subset of an arbitrary 3000+ subscribers to internals, there's an overwhelming majority amongst the principal developers of PHP that voiced an opinion against it. While we have no official rules or structures for voting features into PHP, PHP being a meritocracy, that should be enough to put this RFC to bed. I'd second that. There have been a number of developments added to PHP5 in the last few major versions that offer little but irritation to main stream users. phpdoc is used extensively for documentation, and it would be nice to see THAT fully supporting these other tangents rather than simply inventing a new way of doing the same thing. Lets please finish what we currently have work rather than adding yet another layer of complexity. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #50237 — Will Fitch — 2010-11-16T07:43:39+00:00 URL: https://externals.io/message/50206#50237 · In reply to: #50233 Your answer should have been just that. The overwhelming majority amongst the principal developers of PHP voiced an opinion against it. I can certainly understand the need for a meritocracy in PHP's current state. The benefit of annotations for the masses vs performance hit and complexity isn't currently worth it. Saying developers needing annotations for specific functionality (e.g. SOAP) should make do with phpdoc sends a bad message. > I hope I won't stir the pot too much, but with all due respect to the vote > of at-best a two digit subset of an arbitrary 3000+ subscribers to > internals, there's an overwhelming majority amongst the principal developers > of PHP that voiced an opinion against it. While we have no official rules > or structures for voting features into PHP, PHP being a meritocracy, that > should be enough to put this RFC to bed. > > Zeev > > > […] > support > > […] > in > > […] > as > > […] > next > > […] > instead of > > […] > that > > […] > case of > > […] > (aka. > > […] > support? > > […] > context. > > […] > these parts. > > […] > meaning. > > […] > new > > […] > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fitch@quepasacorp.com Twitter: twitter.com/willfitch --- ## #50246 — Richard Quadling — 2010-11-16T12:32:46+00:00 URL: https://externals.io/message/50206#50246 · In reply to: #50232 > > […] > > You got me...  But as an intelligent human being I'd like to think I can evaluate the merits of a feature without having to actually use it. > > I'm not saying that annotations don't give you any value.  Sure they do.  I'm saying that they come at a great price of adding an obscure branch of syntax into a language that's already grown significantly in complexity, and the bang for the buck isn't worth it.  Those advanced developers needing that feature can make do with phpdoc. > > Zeev Hi all. I use PHPDoc. I develop SOAP services and use ZF to autocreate my WSDL files. I've used tools to create classes from a WSDL file. I don't know how this qualifies specifically as "annotations" - so I'm probably in the same camp as Zeev on this. An issue for me is the lack of ongoing development (it seems) of phpdoc. Yes, sure, it is for documentation. But that is just one sort of annotation. [1] I think having a mechanism which is easily understood in both human and machine terms and obeys a simple, expandable syntax, then this would seem to be extremely useful. I like the idea of JSON encoded annotations. JSON is very simple to understand (if you can manually create a nested associative array in PHP, you can create JSON encoded data). I think for more complex annotations, a simple @tag doesn't seem like it is going to be enough. There is no way to nest the tags in any meaningful and validatable way. At least not in a way that is obvious when you read it. Also, for every new @tag, you have to tell PHPDoc to ignore it as it will produces noise. But consider now the amount of PHPDoc blocks out there. A PHPDoc -> annotations converter would have to be developed. Theoretically, one _SHOULD_ be able to do that using a PHPDoc template - I think - not an area I know well. One issue mentioned is that having annotations will have a "performance hit" on PHP. I'm obviously missing something here. If the annotation is in a blockcomment, then that would seem to satisfy the performance issue. Reading the annotation for normal runtime execution would seem wrong. Only as part of reflection or annotation specific access should the block be "decoded" into whatever form is required. So, aren't annotations really just an extension to the docblock decoding aspects of reflection? Do we have a "performance hit" because of reflection? I know I know very little about the impact on PHP, but a simple syntax wrapped in a comment would really seem to be an ideal approach to me. So much so, I'm almost surprised we need anything in the core at all. Regards, Richard. [1] http://en.wikipedia.org/wiki/Annotation#Software_programming -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY --- ## #50247 — guilhermeblanco@gmail.com — 2010-11-16T13:38:28+00:00 URL: https://externals.io/message/50206#50247 · In reply to: #50233 Hi Zeev, > I hope I won't stir the pot too much, but with all due respect to the vote of at-best a two digit subset of an arbitrary 3000+ subscribers to internals, there's an overwhelming majority amongst the principal developers of PHP that voiced an opinion against it.  While we have no official rules or structures for voting features into PHP, PHP being a meritocracy, that should be enough to put this RFC to bed. Thanks for the input, but that's what I want to see in a democratic way. *YOU* closed the previous thread, saying that "PHP does not need Annotations.". Ok, I may have did something wrong previously, adding new syntax, etc. So I decided to make it more democratic, and identify what can be done in this subject. If you READ what I wrote in the first email of this thread, you may find that I do not add any implementation details. I'm just asking if you agree into more discussion on this topic - on how can it be implemented, syntax, where, etc -, or drop the entire idea completely. So I'd second the same thing I did previously... Let's listen to what people want. I already restricted the counting of votes to people with PHP karma, so meritocracy is perfectly being counted here. Please stick to your vote and let other people vote. Do not close this thread, again. Cheers, > > Zeev > > > […] > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #50248 — guilhermeblanco@gmail.com — 2010-11-16T13:41:20+00:00 URL: https://externals.io/message/50206#50248 · In reply to: #50236 Hi Lester, If you READ my first email of this thread, you'll find out I do not speak about new syntax, etc. No matter if you say "that can be done through docblock", you're automatically saying +1 to this thread. Please re-read the topic and vote. Thanks. Cheers, > ( Try again Zeev changing the pigging address ;) ) > Zeev Suraski wrote: > > […] > > I'd second that. > There have been a number of developments added to PHP5 in the last few major > versions that offer little but irritation to main stream users. phpdoc is > used extensively for documentation, and it would be nice to see THAT fully > supporting these other tangents rather than simply inventing a new way of > doing the same thing. Lets please finish what we currently have work rather > than adding yet another layer of complexity. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > > > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- Next page: https://externals.io/message/50206.md?page=2