Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPg3XxK+ovZVL+MtcoS0AmNGHUOKRU+SwJmn3Z2jt8Ah0xqULA@mail.gmail.com>
References: <CADqTB_h4eh4mPi89uRps6vZWXjDEhUtcBopL7jmO-UgRuyf19w@mail.gmail.com>
	<CAKtZbJ526-QRPmLT34fCeCZBLteeHLrHVrnKeLMCsUkuxoUyfA@mail.gmail.com>
	<CADqTB_gH=14J4Md=H=1ZYD9vjtRiGd+tSb9VTioQy-vzqHq01A@mail.gmail.com>
	<CAPg3XxK+ovZVL+MtcoS0AmNGHUOKRU+SwJmn3Z2jt8Ah0xqULA@mail.gmail.com>
Date: Wed, 9 Jan 2013 08:29:45 +0000
Message-ID: <CAPwsocHDkrGsqvyZKNinUJ73HUvSTU_OVir1MtsQwpf6kXrTeA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d0447850d5b73f504d2d6dd2f
Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader
From: leight@gmail.com (Leigh)

--f46d0447850d5b73f504d2d6dd2f
Content-Type: text/plain; charset=ISO-8859-1

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 <petercowburn@gmail.com> wrote:

> On 9 January 2013 01:08, Rasmus Schultz <rasmus@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.veselinov@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
>
>

--f46d0447850d5b73f504d2d6dd2f--