Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89430
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56560921.4050703@garfieldtech.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> <56560921.4050703@garfieldtech.com>
Date: Wed, 25 Nov 2015 14:29:54 -0500
Message-ID: <CAFp73Xt=TeBDmOzFy18oBoMV1eHtUEVr7oEPtF3WM4U8zMd0PA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011764efc544430525627cfb
Subject: Re: [PHP-DEV] Native Annotation Syntax
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--089e011764efc544430525627cfb
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

I'm avoiding drilling down as much as I can to explain every single
decision motivation of the 2010's patch, which hints every time why
docblocks are bad.
Maybe another example may help you to illustrate the problem; all I want is
to add a multi-lined text in an annotation (using your docblock approach):

/**
 * @Documentation\Description("This
 * is
 * multi-lined.")
 */

Or:

/**
 * @Documentation\Description(<<<EOF
 * This
 * is
 * multi-lined
 * EOF;)
 */

Quickly answer me if every line's * should be part of the string or not. If
not, what about the space after them? How should heredoc work in this case?
Feel free to detail your answers and provide examples.
Things are not as simple as it looks, unfortunately... =(

On Wed, Nov 25, 2015 at 2:16 PM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On 11/25/15 11:48 AM, Rowan Collins wrote:
>
>> Larry Garfield wrote on 25/11/2015 17:39:
>>
>>> On 11/25/15 11:00 AM, Rowan Collins wrote:
>>>
>>>> I don't feel that strongly in favour of docblocks, but I don't think
>>>> the reasons given against are particularly strong.
>>>>
>>>> Regards,
>>>>
>>>
>>> If you don't feel strongly in favor of them, why are you trying to make
>>> a case for them so strongly?  Just for kicks?  We don't need a "devil's
>>> advocate" at this point in the discussion...
>>>
>>>
>> Hi Larry,
>>
>> I don't *feel* strongly in favour or against them, but can see advantages
>> and disadvantages on both sides. Feeling strongly is not the same as having
>> a strong argument for your point of view, so just because some people have
>> expressed strong opinions against, I don't see why I shouldn't challenge
>> their reasoning, even if that does mean playing devil's advocate.
>>
>> Which is better: basing the decision on the gut feeling of a handful of
>> people who happen to be here now, or basing it on sound reasoning after
>> thinking through the implications?
>>
>> Regards,
>>
>
> So far, the only argument FOR them is BC with existing practices.
> Everything else I've seen is, I think, ways around the issues that raises.
> However, as has been noted the BC is spurious as it would only be BC with
> one implementation out of several, and we've never polyfiled other
> syntax-level features that I can recall.  (We've polyfilled new functions,
> but that's easy.)
>
> By the same argument, we should have used docblocks for scalar types, too,
> so that they could be polyfilled and be BC with existing practices, and
> those would have even been fairly standardized already.  Someone even made
> that point, IIRC, and it was quickly rejected.
>
> Whereas as a stand-alone syntax, it offers a much better distinction
> between "metadata that affects code execution" and "stuff for humans to
> read" (both for parsers and for humans).  It gives us much more flexibility
> to implement a meaningful API.  It completely avoids the "but comments
> shouldn't be code" question (which is a bigger deal than you'd think; it
> was one of the drivers behind the Backdrop fork of Drupal. I'm not kidding.)
>
> That one of the lead authors of the most widely used comment-based
> annotation system in PHP is arguing what a terrible idea a comment-based
> annotation system is should carry a great deal of weight.
>
> --
> --Larry Garfield
>
>
>
> --
> 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

--089e011764efc544430525627cfb--