Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVpe3+9=N5rkcHp2O5cdGuFnt_EQ=sSV8ucpv5w=ox-NaA@mail.gmail.com>
References: <CAJGzsHriGp9PoYq++=CBQptFYZQiAsa+yxxN076BHxMQGD6HrA@mail.gmail.com>
	<5654B516.4020700@gmail.com>
	<CAESVnVpe3+9=N5rkcHp2O5cdGuFnt_EQ=sSV8ucpv5w=ox-NaA@mail.gmail.com>
Date: Wed, 25 Nov 2015 09:04:32 -0200
Message-ID: <CAJGzsHoP5mc2_demfWM3r7exN4qLThANcbcwo9SBydGpvmB1WQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c07709a421e9405255b6c95
Subject: Re: [PHP-DEV] Native Annotation Syntax
From: pedronaroga@gmail.com (Pedro Cordeiro)

--94eb2c07709a421e9405255b6c95
Content-Type: text/plain; charset=UTF-8

I'd really like to see something outside the docblock. Comment annotations
are a workaround for the lack of native annotations. It makes the
environment hard to learn ("What does @param do? And what does @ManyToMany
do?"), it makes it impossible for IDEs to hint/autocomplete without
project-specific plugins, and adds this odd notion that removing some
comment blocks might break an app (which is just awful).

@beberlei, I had searched through the archives already and couldn't find
the vote. I found the discussion (in which many people advocated for
docblock annotations), but didn't find the vote.

I feel like this is a major feature that's missing, and people are using it
in a suboptimal way (docblocks), so I thought I'd reopen the discussion and
see if someone more familiar with the internals feels like implementing it
(I don't feel confident enough since I've never tried messing with into the
internals).

2015-11-24 22:31 GMT-02:00 Sara Golemon <pollita@php.net>:

> On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins <rowan.collins@gmail.com>
> wrote:
> > At first sight, these seem like details which could be tweaked later, but
> > they make a difference to what syntax to standardise: is the annotation
> name
> > just a string, or a valid class name? is the value of the annotation
> just a
> > string, or a parseable PHP expression? is it more useful to use the de
> facto
> > existing syntax in DocBlocks, or to add a new keyword or operator? etc
> >
> If we're going to use something in the docblock, then I wouldn't want
> it parsed on compilation, but rather have it be an on-demand parse
> while reflecting.  The reason being that there are plenty of
> docblock'd PHP libraries out there using invalid annotations because
> they're not running it through tools to tell them what they got wrong.
> Waiting till they've actually tried to examine it through reflection
> lets us throw an exception on code that cares about it rather than
> preventing code which ignores reflection from running.
>
> I, for one, am a fan of Java style annotations which allow a string
> name plus optional metadata.
>
> @@foo
> class Bar {
>   @@Baz("something", 123, [ 'a', 'b', ''c'])
>   public function qux() { ... }
> }
>
> Though the formality of having to define the annotation as an
> interface is a bit overkill for PHP, the same rules Hack uses would be
> clear and simple enough:
>
> <<foo>>
> class Bar {
>   <<Baz("something", 123, [ 'a', 'b', 'c'])>>
>   public function qux() { ... }
> }
>
> And no, I'm not picky about the parser symbol used...  In fact,
> allowing an optional '//' prefix to annotations might be nice for
> compatibility.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c07709a421e9405255b6c95--