On Tue, Aug 11, 2020 at 6:26 PM Andreas Leathley <a.leath...@gmx.net> wrote:
> On 11.08.20 18:07, Sara Golemon wrote:
> > Writing this on PHP 7 (or any earlier version for that matter) would be
> > valid syntax (ignored as a comment):
> >
> > #[SomeAttr(123)]
> > function someFunc() {}
> >
> > That's what's meant by Forward Compatibility. Library/Framework authors
> > could aggressively adopt attributes with the #[...] syntax, they can NOT
> do
> > so with any other syntax.
>
> This would be a feature if libraries start parsing PHP token by token
> and start supporting the #[] syntax for the 7.x versions of PHP - then
> early adoption would be possible and it would be a real feature. But it
> seems unclear if that will happen, as it will probably have a heavy
> price on performance (and might have some complexity). And if some
> libraries implement it but others don't, then it might get confusing for
> users about why the new attribute syntax sometimes works and sometimes
> silently does nothing.
>
> It is also not perfect as multi-line attributes with #[ still break, or
> code with #[] followed by more code instead of a newline and then more
> code.
>
To clarify the forward compatibility argument: As far as I understood, it's
not really about the end user, it's about the library implementing the
attribute. The library providing the Route attribute can write:
#[Attribute]
class Route
{
// ...
}
and make the Route attribute available both for use with PHP 8 attributes
and PHP 7 docblock annotations. With non-FC syntax choices this possibility
does not exist, and the library will be required to provide different class
hierarchies for docblock attributes and PHP 8 attributes.
The ability to write #[Route] for the user of that library is an additional
possibility on top of that, but one that is technically more involved. I
think the primary forward compatibility value lies in the above usage.
I believe this was explained in some of the earlier discussions, but I
wanted to repeat it in this thread, as there seems to be some confusion on
this point.
Regards,
Nikita
