Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55cfd01c70ea2798a700a083a6c36935@naenius.com>
References: <CADqTB_h4eh4mPi89uRps6vZWXjDEhUtcBopL7jmO-UgRuyf19w@mail.gmail.com>
 <50EBDEEE.8070605@sugarcrm.com> <CADqTB_gMcDU69N=SNR-uCOmmbvXfEJ8dFYxpvZmgbK7XTXUsUA@mail.gmail.com>
 <55cfd01c70ea2798a700a083a6c36935@naenius.com>
Date: Wed, 9 Jan 2013 01:16:38 -0500
Message-ID: <CAFp73XtJdbc+2SsprWM3tbQRfPf=s6Rar+POEhkOPxcRZvbwTg@mail.gmail.com>
To: Mike van Riel <mike.vanriel@naenius.com>
Cc: Rasmus Schultz <rasmus@mindplay.dk>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93408df7e425a04d2d5024f
Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--14dae93408df7e425a04d2d5024f
Content-Type: text/plain; charset=UTF-8

But I can add more.

Filtering
Validation
Form declaration
Database mapping
Joinpoint definitions (AOP)
Service Injection (look at FLOW3)
Testing
etc

Basically everything can define constraints or usage of an element,
behavior, process or nature of an element.
Let me give some individual examples:

Constraints: @MinLength, @NotNull
Behavior: @Transactional, @Inject
Process: @Column, @XmlElement, @OneToOne
Nature: @Entity, @Table, @WebService, @TestCase

Makes more sense now?


On Wed, Jan 9, 2013 at 1:01 AM, Mike van Riel <mike.vanriel@naenius.com>wrote:

> On 09.01.2013 02:38, Rasmus Schultz wrote:
>
>> A native implementation of PHP-DOC block parser for run-time purposes
>> (annotation libraries) is already available in the Reflection API,
>>
>
> There is no DocBlock parser in the Reflection API; you can merely
> retrieve the T_DOC_COMMENT token.
>
>
>  and
>> already goes as deep as it needs to - going beyond simply finding and
>> extracting the docblocks would make little sense, as every annotation
>> library has it's own individual syntax, behaviors and features.
>>
>
> There are other types of project that benefit from the parsing of the
> actual DocBlock without any support for Annotations. Examples follow below.
>
>
>  There may
>> be a some libraries that could use a native implementation if it happens
>> to
>> fit their needs, but they most likely won't use it, because (A) they won't
>> win anything by doing so, and (B) these libraries would become
>> incompatible
>> with anything other than bleeding-edge PHP.
>>
>
> I disagree with this,
>
> A) Said applications and libraries win in the terms of performance and
>    standardization; this will offer a baseline for IDEs to offer proper
>    support for descriptions and tags and even more advanced features.
> B) This issue arises with _any_ new feature that substitutes or empowers
>    a userland functionality and I thus consider it a non-argument.
>    I am Lead Developer of phpDocumentor and I promise you, I'd use this.
>
>
>  A native implementation of PHP-DOC parser for offline purposes
>> (documentation generators) is already available in userland, does the job
>> fine, and does not rely on the Reflection API (as someone mentioned)
>> because loading every class in a large codebase is not feasible. If you
>> provide a separate PHP-DOC parser, these projects most likely won't use
>> it,
>> because (A) see above and (B) see above.
>>
>
> Performance is key with documentation generators. Since DocBlocks are the
> most prevalent thing in a code base they could win with a core
> implementation.
> Also, as provided earlier, would standardization benefit the whole
> community
> that consumes DocBlocks and IDE vendors.
>
>
>  Who else would need to parse PHP-DOC blocks and why?
>>
>
> * WSDL Generators to extract descriptions and type information
> * REST API documentation generators for the same reason
> * HATEOAS libraries could benefit from the reading of the @uses tag
> * Command Line Application frameworks could use the Command class'
> description
>   for their help screen.
>
> And more uses that I cannot think of within a few seconds.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--14dae93408df7e425a04d2d5024f--