Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.217.193 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Thu, 21 Apr 2016 19:15:35 -0700
Message-ID: <CAESVnVrNqpqsTUCdHiQi8j3d4KVz8ZqRh6pEVJegR-EsmFN3_g@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: pollita@php.net (Sara Golemon)

On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> I would like to present an RFC proposing support for native annotation.
>
I'm trying to imagine where the benefit of non-constant expressions comes in.

<<foo($a < 1)>>

Assuming we roll in php-ast at the same time (which is a big addition,
IMO, and deserves its own separate RFC), what are users meant to do
with this?  Even if there's a use-case here, one could accomplish the
same thing with:

<<foo('$a < 1')>>

And manually running that string into php-ast if that's what the caller wanted.

Also, maybe I missed it, but I didn't see an answer to the question of
ambiguity between parsing the above as a straight string, versus
parsing it as a ZEND_AST_ZVAL.  I'm sure the answer is "If the AST
tree is just a ZVAL, then it's provided as the compile-time
expression, but what about something else like this:

<<foo(1+1)>>

Logically, this is reducible to a single compile-time value, but it's
a complex expression, so would it be the value int(2)? Or
ZEND_AST_BINARY_OP(int(1), int(1))?

I just think that over-engineers what should be a simple annotation feature.

All that said, I love the proposal overall, and I can't wait to
propose builtin annotations like <<__Memoize>>, <<__Mock>>, and
similar.

-Sara