On Wed, Jan 9, 2013 at 10:29 AM, Leigh <lei...@gmail.com> wrote: > In my opinion (for however little it matters), code is code, and comments > are comments. They should not mingle. > > Annotations, if implemented, should have their own syntax that makes them > code, not an abstraction of a comment. > > I already dislike the fact that getDocComment is there - in my opinion all > _comments_ should be discarded. That said, if people want to parse > annotations from doc block comments, getDocComment _is_ already there and > that is all they need to build a parser (imho). Annotations from doc blocks > could quite easily be an extension building on top of getDocComment. > > I support annotations. As code, not comments. > > > On 9 January 2013 08:09, Peter Cowburn <petercowb...@gmail.com> wrote: > > > On 9 January 2013 01:08, Rasmus Schultz <ras...@mindplay.dk> wrote: > > > I've started working on a new proposal, but I'm getting hung up on the > > > syntax - if we can't use angle brackets anymore, what can we use? > > Virtually > > > every symbol on a standard US keyword is an operator of some sort, does > > > that mean those are all out of the question? > > > > > > e.g. thinking of concrete possible basic syntax, neither of the > following > > > delimiters would work: > > > > > > [Foo('bar')] > > > > Why would this not work? I'm struggling to think of a place where one > > would want to use an annotation where it could be misinterpreted as an > > array literal. If anything, the visual "conflict" or association with > > the array syntax is a good thing in my book: my brain parses it as an > > array of one or more annotations. > > > > > > > > <Foo('bar')> > > > > > > {Foo('bar')} > > > > > > And presumably none of the following would work either: > > > > > > ~Foo('bar') > > > @Foo('bar') > > > ^Foo('bar') > > > *Foo('bar') > > > &Foo('bar') > > > :Foo('bar') > > > > > > Can you think of anything that would work? > > > > > > > > > On Tue, Jan 8, 2013 at 3:57 AM, Vladislav Veselinov > > > <v.veseli...@gmail.com>wrote: > > > > > >> Assume that you have this class with your proposed syntax: > > >> > > >> [SomeAnnotation('somevalue')] > > >> class Test { > > >> > > >> } > > >> > > >> This conflicts with the short array syntax. It looks like an array > > >> containing the result of the function 'SomeAnnotation' invoked with > > >> the parameter 'somevalue'. > > >> The only difference is the missing ";" but relying on this to > > >> determine whether this is an annotation or not would be insane. > > >> I'd support such a decision but with other syntax. > > >> > > >> I like Guilherme's RFC. I just don't think that the syntax is very > > PHPish. > > >> > > >> > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
We're circling the same point again and again, don't we? It seems like almost everybody supports annotations - but as a feature and not by using the doc-comment. I, too, agree with that concept. Related to doc parsing - we can implement such a feature anyway, which can be live inside: - Reflection API - SPL - Separate extension that'll live inside PECL and not in the core. I think that it should be live in the core for anyone who wish to use it, however, as long as annotations will be implemented - I'll be very happy and satisfied. About the syntax: in case we still can't use the brackets or < and >, we can do something like... [metadata: Foo("")] [metadata: Bar("")] public function baz() { ... } so we'll use the metadata: prefix that'll make it difference than standard arrays construction. What do you think?