Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94300
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6s+cNM0RMpvGF_0qmhU1Wpx=_zK6O3kKLxUr-Vu-7jJXNg@mail.gmail.com>
References: <CADqTB_i5WL+rzCuFHkRmXsPj16WDc4eWmpAoFmyeuYXvuOP_NQ@mail.gmail.com>
 <211db59e-9c22-6df4-1f72-66ebbc5095bd@fleshgrinder.com> <CADqTB_gyjkVZ50c1x=c4mUSs3q0UvzzZdcLm6iJZGD=E+2n1VA@mail.gmail.com>
 <CADyq6s+cNM0RMpvGF_0qmhU1Wpx=_zK6O3kKLxUr-Vu-7jJXNg@mail.gmail.com>
Date: Tue, 28 Jun 2016 11:30:42 -0300
Message-ID: <CAJGzsHojxcw-KBDw+c8RkF9c2qCRkfKkm-VXQCSa4PaRmmT5KA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Rasmus Schultz <rasmus@mindplay.dk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1147a51c5534b30536577bc4
Subject: Re: [PHP-DEV] [RFC] Simple Annotations
From: pedronaroga@gmail.com (Pedro Cordeiro)

--001a1147a51c5534b30536577bc4
Content-Type: text/plain; charset=UTF-8

I completely agree with Marco. Throwing class-loading errors for
value-object classes is alright. For logic-parsing inside annotations, I
don't feel any need for it. Metadata should be static, IMO, but it could
very well be (and should be) value-objects.

>At the end of the day, what we end up with will have all of the same
>issues we have with php-doc blocks and existing libraries.
>
>I don't understand how such a feature would be useful to anybody?

As an addition, I don't think this feature should ADD new functionality to
those already present on DocBlocks. I just feel like docblocks are an ugly
hack for the lack of native annotations. Pasting from a previous discussion
in this same list, Rowan and I were discussing whether to add a native
docblock-annotation-retrieval feature or a native annotation syntax:

1) It 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) Dockblocks are stripped from obfuscators and transpilers, which are a
part of the ecosystem and do affect users, even if they are not first-class
citizens here.

Annotations in dockblocks are hard to understand because they they may or
may not be runtime-affecting annotations and there is no way to tell.

I hate this comparison with docblock annotations, because they are an UGLY
HACK. It works wonderfully, yes, but so do global variables, singletons and
what-not, and we are not using them anymore, are we? Adding this very same
feature that already exists in userland as a dedicated syntax would fix a
lot of issues, cited above. There is no need to evaluate logic inside
annotations, let them be value-objects, let it throw errors autoloading
said objects, and let's get this rolling.

Please, don't embargo this ONCE again. It's a very much needed feature, and
people want it! There have been innumerous discussions on reddit, and
almost everyone agrees annotations are a missing feature and
comment-annotations are an ugly hack for the lack of native syntax.

Please, make this happen.

2016-06-28 11:12 GMT-03:00 Marco Pivetta <ocramius@gmail.com>:

> Hi Rasmus,
>
> On 27 June 2016 at 20:37, Rasmus Schultz <rasmus@mindplay.dk> wrote:
>
> > Tonight I started trying to write a proposal for even more simplified
> > annotations, e.g. something simple enough that it cannot result in
> > fatal errors. I eventually gave up, and here's why.
> >
> > Essentially, if you have to restrict yourself to things that cannot
> > under any circumstances error out, the only things you can use are
> > constant scalar values - even constant scalar expressions could not be
> > allowed, because even those could error when CONST_NAME or
> > Class::CONST_NAME aren't defined.
> >
> > So, in a nutshell, what you're saying (Richard) is that annotations
> > can only consist of scalar values, and possibly arrays of values? (and
> > I don't even see your gist doing that - it's just invoking closures,
> > as far as I can tell, and any of those could error, or not?)
> >
> > So, regardless of syntax, literally the only annotation data allowed
> > would be blatantly simple things like:
> >
> >     ["max_length" => 20]
> >
> >     ["data_type" => "int"]
> >
> > Or in other words, constant arrays, int, string, float and bool
> > values. Nothing else.
> >
> > Nothing can depend on any kind of external symbol (class names,
> > constants, etc.) since any such reference can cause an error.
> >
> > No static analysis or type-checking of any kind can ever be performed
> > - no assertions or declarations can be made about the shape or types
> > of metadata, at all.
> >
> > The problem is, that's simply not useful.
> >
>
> That's actually what doctrine/annotations has been for a while  tho, and a
> lot of people rely just on that.
> The data-structure is still enforced by a VO-style class (the annotation
> itself) in the library, though.
>
> It would still be very useful, in my opinion.
>
> Note that the existing annotation libs out there do indeed trigger
> autoloading for referenced class constants.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

--001a1147a51c5534b30536577bc4--