Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.41 cause and error)
MIME-Version: 1.0
In-Reply-To: <211db59e-9c22-6df4-1f72-66ebbc5095bd@fleshgrinder.com>
References: <CADqTB_i5WL+rzCuFHkRmXsPj16WDc4eWmpAoFmyeuYXvuOP_NQ@mail.gmail.com>
 <211db59e-9c22-6df4-1f72-66ebbc5095bd@fleshgrinder.com>
Date: Mon, 27 Jun 2016 20:37:01 +0200
Message-ID: <CADqTB_gyjkVZ50c1x=c4mUSs3q0UvzzZdcLm6iJZGD=E+2n1VA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Simple Annotations
From: rasmus@mindplay.dk (Rasmus Schultz)

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.

It's also not very different from what we have today with php-doc
blocks - the only real difference is we can check array nesting and
int, string, float and bool syntax, e.g. nothing really useful or
important.

In other words, this would be a very slight improvement on syntax -
nothing that actually amounts to any kind of functionality.

If we were to ship a feature like that, what would happen is precisely
the same thing that happened with php-doc blocks: the real work will
be done in userland (and likely dominated by one library), there will
be no IDE support (except proprietary support for that one dominating
library), no useful offline static analysis tools.

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?

I especially don't understand why you want a language feature that
isn't allowed to reference external symbols - e.g. isn't allowed to
have any kind of relationship with anything declared in userland.

It seems to me a peculiar, arbitrary and unrealistic restriction to
put on annotations.

It's going to have no immediate usefulness, and mapping the data to
objects is going to happen in userland, just as it does today.

I'd like to work on this proposal, but I feel that you're giving me
nothing to work with here.


On Mon, May 16, 2016 at 12:38 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 5/13/2016 2:11 PM, Rasmus Schultz wrote:
>> Dear Internals,
>>
>> I'm announcing a simplified RFC for annotations:
>>
>> https://wiki.php.net/rfc/simple-annotations
>>
>
> -1 again, I am sorry.
>
> The problem is that an annotation by definition is just meta-data. Your
> proposal however might result in fatal errors from meta-data:
>
>   $reflector = new ReflectionClass(User::class);
>   $reflector->getAnnotations();
>
>   // Fatal error: Uncaught Error: Class 'TableName' not found ...
>
> This is an absolute No-Go for meta-data.
>
> --
> Richard "Fleshgrinder" Fussenegger
>