Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64653 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38418 invoked from network); 8 Jan 2013 03:43:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jan 2013 03:43:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=guilhermeblanco@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=guilhermeblanco@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.44 as permitted sender) X-PHP-List-Original-Sender: guilhermeblanco@gmail.com X-Host-Fingerprint: 209.85.219.44 mail-oa0-f44.google.com Received: from [209.85.219.44] ([209.85.219.44:58535] helo=mail-oa0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 05/10-37176-1D59BE05 for ; Mon, 07 Jan 2013 22:43:13 -0500 Received: by mail-oa0-f44.google.com with SMTP id n5so18916977oag.17 for ; Mon, 07 Jan 2013 19:43:10 -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=pzW9pDUWwT9Uh1KWW9TUni9ROyY6T4/h3dFZcRWuVR8=; b=E5c6Iz109gJxeE3q2vMsHV5ij1DhEpTHVYxNxQKjPle3Dvwg0Xwh6XUTBar65N35GC y62lGNUwFqdYjrq3QxgdIE6JtDT2FCGnVlvMpxOGvL2Y9DSiwUppLLGHTDXWjy8nndMh 2rcfSOvDSvxPYNStUjI7op+HJudUCMM7JPvgza1zuuFbueIqEoOi6EdBlm7xihZAKapf p+nNg7l3rtbiUXVOlkuBieYLnblgUnT6zz9jzOiBAZuzJHKthXMO1LB8wpBgSLYJaHGN USLulQ7svDgCpTEgdsC7zgeP5CHq5V+hrdwTl9V4qcgnr/vcIFwND/LLlHHeq8G9DhUo jojA== Received: by 10.182.88.38 with SMTP id bd6mr3165629obb.19.1357616590799; Mon, 07 Jan 2013 19:43:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.174.68 with HTTP; Mon, 7 Jan 2013 19:42:50 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Jan 2013 22:42:50 -0500 Message-ID: To: Rasmus Schultz Cc: PHP internals Content-Type: multipart/alternative; boundary=14dae9340b1ba2c1ba04d2bebebc Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com") --14dae9340b1ba2c1ba04d2bebebc Content-Type: text/plain; charset=UTF-8 Cof... cof... https://wiki.php.net/rfc/annotations Good luck convincing php-src folks. You'd be my hero. On Mon, Jan 7, 2013 at 9:50 PM, Rasmus Schultz wrote: > On parsing annotations in docblocks: please don't. > > First of all, there are already plenty of established userland > implementations - so there is really no need for this. > > Whatever you decide on in terms of syntax, most likely won't satisfy every > the needs of every userland annotation library, so at least some of them > most likely won't use it. You'd be creating more work for the maintainers > of these frameworks, and they don't standard to gain anything from that > work. > > In terms of performance, there is nothing significant to gain here - any > good annotation engine/framework already caches parsed annotations. > > On the other hand, I would be interested in having support for actual > annotation syntax (not docblocks) added to PHP. Real annotation syntax > could have benefits over parsing docblocks, starting with the fact that > most of what's currently in docblocks is documentation, and thus not very > interesting at run-time for anything other than documentation generators. > (again, documentation generators already have working parsers, and don't > stand to gain anything significant from switching to a native docblock > parser.) - also mind the fact that docblocks are a loose standard with many > more variations since annotation libraries came around. > > The only real downside (in terms of run-time) to adding custom syntax, is > that existing useful annotations (such as @var for property-types) would > not be useful - but in another sense, that's a good thing, because (for the > most part) in existing codebases, these were written as documentation, not > intended for run-time consumption. IDEs and documentation tools can add > support for new annotation syntax, and treat these consistently and code, > which itself can be documented using phpdoc blocks. > > I would support and encourage a C# style syntax and behavior, e.g.: > > use my\lib\DataType; > > [DataType('datetime')] > public $published_date; > > In other words, DataType is a class, implementing an interface for > initialization - everything between the parentheses is interpreted > basically the same way as in an array() statement, and is passed to the > annotation instance after construction via an initialization method defined > by the interface. > > I could elaborate tons more on this subject, as it's something I have spent > a lot of time researching in different languages, prior to writing my own > annotation library. > > It may strike you as odd that someone who implemented an annotation library > based on docblocks is actually against annotations in docblocks - I mainly > chose that option because it was the best option at the time. I'm not a C > programmer, and I do believe that docblocks are the best approach for a > native PHP implementation. For a native implementation, I'd prefer to see a > clear separation between non-functional documentation metadata and > functional annotation objects. While there is some overlap between the two, > much of what is currently written as documentation (for example @var > annotations) could be written as functional annotations when these have a > meaningful purpose. After all, existing code with phpdoc-annotations most > likely was not written with the intent of consuming that metadata at > runtime, unless written for use with an annotation library. > > I would be happy to involve myself deeper in this, if others agree and > would like to work on a new RFC. > > - Rasmus Schultz > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --14dae9340b1ba2c1ba04d2bebebc--