Hi, Rowan. I'll respond to some points that have become recurrent.
1) It's might not be objectively bad to add this feature in docblocks, but
it will be objectively wrong to keep calling them "DocBlocks" if they are
no longer documentation-only blocks.
2) Even though PHP already treats docblocks differently from comments,
that's not the common view on userland, nor is explained on the manuals.
There are no separate entries to explain docblocks, and no mention to them
on the "Comments" page. The Reflection method to retrieve DocBlocks is
"getDocCOMMENT", which suggests they are comment that do not affect runtime
behaviour.
We'd have to update the comments page to say "'/*' starts a comment, unless
if they're immediately followed by another asterisk ('/**'), in which case
it may or may not be a comment, depends on the following token". It's very
confusing.
3) To make this work within docblocks, we'd have to get rid of at least one
configuration setting (opcode.save_comments).
4) You've suggested disregarding docblock stripping from transpilers and
obfuscators, because they are not first-class citizens, even though those
are part of the PHP ecosystem and affect users.
5) We'd have a harder time making decisions on syntax for docblocks,
because there are already multiple different implementations, and because
people will have a hard time agreeing on some points, like the one
guilherme made about the asterisks (*) or spaces being part of multiline
annotation or not.
Whereas none of these points are issues for a native syntax outside
docblocks, because it'd be a completely different feature that would reside
in new syntax, not in modification of current syntax.
2015-11-26 8:06 GMT-02:00 Rowan Collins <rowan.coll...@gmail.com>:
> guilhermebla...@gmail.com wrote on 26/11/2015 01:13:
>
>> Ok, so I'll explain why it's not "the same way" as you imagine.
>>
>> I've heard this many times already so I'll save you keystrokes.
>> - "Sure, we can do that on docblocks"
>> - "Based on that, it doesn't need to be part of core and can safely be
>> implemented as a PECL extension"
>>
>>
> OK, as far as everything I was talking about, this is all rather a straw
> man, but perhaps that's just a miscommunication on my part, so let me clear
> that up:
>
> I have never suggested, and would not support a suggestion, that this be
> implemented as an extension. I can absolutely see the advantage to having a
> first-class syntax, baked into the main parser.
>
> With that out of the way, we are back to the main point I was trying to
> make which is that that syntax could, if we wanted, live inside the context
> of /** */ blocks, which are already treated differently from comments. The
> parsing problems within that context are very similar to the parsing
> problems in any other context (again, assuming that this is being
> implemented directly in the core parser, not in any kind of extension).
>
> So, the pros and cons of that are not to do with the parsing but to do
> with:
> - potential compatibility with existing code, which may be tricky as there
> is no standard to base the feature on
> - the ability to polyfill code in older PHP versions, which is useful but
> not something we have aimed for with previous features
> - on the other side, the perception that docblocks are "just comments",
> which would be hard to dispel even if we renamed them "metadata blocks"
>
> Anyway, I apologise for drawing out this part of the discussion for so
> long. I actually think it's just one of many decisions that needs making
> before this feature can be attempted, probably starting with just what an
> annotation consists of - is it a label with some text attached? a resolved
> class name with parsed PHP code passed to its constructor (some people have
> mentioned arrays and heredocs as parameters to annotations)? somewhere
> between the two?
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
