Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89433
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFp73Xtv2oL+GdOhZGFGRn4DJS_X-u=ZUv5XX5o+L1=r6gq=YQ@mail.gmail.com>
References: <CAJGzsHriGp9PoYq++=CBQptFYZQiAsa+yxxN076BHxMQGD6HrA@mail.gmail.com> <5654B516.4020700@gmail.com> <CAESVnVpe3+9=N5rkcHp2O5cdGuFnt_EQ=sSV8ucpv5w=ox-NaA@mail.gmail.com> <CAJGzsHoP5mc2_demfWM3r7exN4qLThANcbcwo9SBydGpvmB1WQ@mail.gmail.com> <5655D82A.8020304@lsces.co.uk> <CAJGzsHr3XfxRGA8DSkLzAf-8AQvJPu1GMVE30PX=ScygMPgCPQ@mail.gmail.com> <5655E4E4.8070200@garfieldtech.com> <5655E61E.3000904@gmail.com> <CAJGzsHp95tp9kTB14JfUmzZ_tn-1EbD1_p9MCE59GH96AX_5DQ@mail.gmail.com> <5655E93F.90506@gmail.com> <5655F24B.6020401@garfieldtech.com> <5655F47C.3060504@gmail.com> <CAFp73Xv_Ya97B7YmLLvZFF32BJkQxUiZo3yu+7_H9RrfefNBCA@mail.gmail.com> <CAJGzsHqOyWX2pD+0D0+GuAHDVmuB+HpOxWftY_3ORJQ+-CQ4VQ@mail.gmail.com> <CAFp73Xtv2oL+GdOhZGFGRn4DJS_X-u=ZUv5XX5o+L1=r6gq=YQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Wed, 25 Nov 2015 22:03:43 +0000
To: PHP internals <internals@lists.php.net>
Message-ID: <1B1E6CD7-2378-43CA-A636-83383707AF8E@gmail.com>
Subject: Re: [PHP-DEV] Native Annotation Syntax
From: rowan.collins@gmail.com (Rowan Collins)

On 25 November 2015 19:02:37 GMT, "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com> wrote:
>Hi Rowan,
>
>If you're in a shared hosting, you can't "simply" remove the
>configuration
>variable.
>Relying on extensions or configuration flags to support core language
>features is very bad. We don't have flags that can turn IF support off
>for
>example, why we would have that for annotations?

I think you misunderstood: I didn't mean that users would need to turn that feature off, I meant that that feature would be removed, and docblocks would always be saved. 


>I can bring more cons if you want... like how/when to parse "use" calls
>in
>a docblock

In exactly the same place you'd parse them outside a docblock.

I really don't understand all these arguments about the parsing being harder. The only difference is that you're parsing /** @Foo */ instead of <<Foo>> or whatever other syntax anyone comes up with.

Really the only difference is that a docblock means sharing with other metadata (directives for generating documentation). Which has the advantage of being polyfillable from older versions of PHP, but the disadvantage of not being as clearly separated as a new type of syntax. Oh, and the perception, right or wrong, that docblocks are "just comments", rather than metadata containers, which Drupal's experience may demonstrate is more important than a purely rational analysis would suggest.

All the other details about how this or that tool will adapt, how whitespace and multiline values should be handled, etc, are going to need just as much thought whatever the syntax looks like.

Regards,

-- 
Rowan Collins
[IMSoP]