Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64713
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
References: <CADqTB_h4eh4mPi89uRps6vZWXjDEhUtcBopL7jmO-UgRuyf19w@mail.gmail.com> <50EBDEEE.8070605@sugarcrm.com> <CADqTB_gMcDU69N=SNR-uCOmmbvXfEJ8dFYxpvZmgbK7XTXUsUA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CADqTB_gMcDU69N=SNR-uCOmmbvXfEJ8dFYxpvZmgbK7XTXUsUA@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <9B10AB21-6037-4FC2-B9DA-67FDD1578077@zerocue.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>,
 "internals@lists.php.net" <internals@lists.php.net>
Date: Tue, 8 Jan 2013 20:06:33 -0600
To: Rasmus Schultz <rasmus@mindplay.dk>
Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader
From: cpriest@zerocue.com (Clint Priest)

If we had true annotations, its certainly something the engine could put to u=
se...  See my previous post in this thread.

-Clint

On Jan 8, 2013, at 7:38 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:

> To summarize:
>=20
> A native implementation of PHP-DOC block parser for run-time purposes
> (annotation libraries) is already available in the Reflection API, 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 may
> be a some libraries that could use a native implementation if it happens t=
o
> 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 incompatibl=
e
> with anything other than bleeding-edge PHP.
>=20
> 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.
>=20
> Who else would need to parse PHP-DOC blocks and why?
>=20
> Bottom line, who is this feature for, what will they do with it, and most
> importantly, why would they use it?
>=20
>=20
> On Tue, Jan 8, 2013 at 3:55 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:
>=20
>> Hi!
>>=20
>>> First of all, there are already plenty of established userland
>>> implementations - so there is really no need for this.
>>=20
>> On the contrary, plenty of implementations means there's a need in this
>> functionality, and it might be a good idea to have one standard
>> implementation if it can cover like 80% of use cases.
>>=20
>>>=20
>>> 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 maintainer=
s
>>> of these frameworks, and they don't standard to gain anything from that
>>> work.
>>=20
>> Since when "it does not satisfy all needs of all users, and some of them
>> may end up not using it" is an argument for not including functionality?
>> And how it's more work for maintainers if they just won't use it?
>>=20
>>> On the other hand, I would be interested in having support for actual
>>> annotation syntax (not docblocks) added to PHP. Real annotation syntax
>>=20
>> Can we please not hijack the topic? We discussed annotations many times
>> already, if you have better proposal than current RFCs please create
>> your own RFC (or ask one of the current RFC authors for collaboration)
>> and start a new topic
>>=20
>> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227
>>=20