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?
