Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64720 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60276 invoked from network); 9 Jan 2013 08:36:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Jan 2013 08:36:11 -0000 Authentication-Results: pb1.pair.com header.from=g.b.yahav@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=g.b.yahav@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.172 as permitted sender) X-PHP-List-Original-Sender: g.b.yahav@gmail.com X-Host-Fingerprint: 209.85.216.172 mail-qc0-f172.google.com Received: from [209.85.216.172] ([209.85.216.172:35914] helo=mail-qc0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3C/01-52225-9FB2DE05 for ; Wed, 09 Jan 2013 03:36:10 -0500 Received: by mail-qc0-f172.google.com with SMTP id b25so1409281qca.17 for ; Wed, 09 Jan 2013 00:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mQnpFyDjOPbBeaIHPUex7w7JWixBZsmRYCs59UZH9M4=; b=XsB6qyggevd8DYivJzJ9KQth5EnOlPqcETqWpuis2Fgw/jjK7EQtVRJjK0rCSuUmEq Oc8ft0JtuvGMKSj0ZK9EUU3eAzqIV3doshJiQwz/hHTfeyLA02Of8P0bzz5ktrV0q26E xroKVRf4ZM9gLHPUFmJyvwBXA5YXF3ONU9FsG0sEnXk/tn/GHWPFTamBftjy6LtctSq0 2qEdHQrMVCzyB8pUKbevjvK/1BLMXZEMyTJ42kCtkkxm3IFaSeJBZjqWh5bvgbamw6V6 vMQpwrlcXfaainZjrPCeVSvypCnD70enU8/Q62xPMpJCII7q4S8jKS4GIx/+AjYV134Q /H5Q== Received: by 10.224.17.193 with SMTP id t1mr47948679qaa.89.1357720567177; Wed, 09 Jan 2013 00:36:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.121.163 with HTTP; Wed, 9 Jan 2013 00:35:47 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Jan 2013 10:35:47 +0200 Message-ID: To: Leigh Cc: PHP internals Content-Type: multipart/alternative; boundary=bcaec51b16d51c613a04d2d6f42f Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader From: g.b.yahav@gmail.com (Yahav Gindi Bar) --bcaec51b16d51c613a04d2d6f42f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 9, 2013 at 10:29 AM, Leigh 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 wrote: > > > On 9 January 2013 01:08, Rasmus Schultz 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')} > > > > > > 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 > > > 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? --bcaec51b16d51c613a04d2d6f42f--