Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93081
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 as permitted sender)
To: Dmitry Stogov <dmitry@zend.com>, Larry Garfield <larry@garfieldtech.com>,
 'PHP internals' <internals@lists.php.net>
References: <5723F2AE.2020806@garfieldtech.com>
 <d158ceff-b888-604c-387c-942239c0e783@zend.com>
Message-ID: <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
Date: Wed, 4 May 2016 23:48:21 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <d158ceff-b888-604c-387c-942239c0e783@zend.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> It's also possible to write:
> 
> <<Drupal(@Block([
>       "id" = "system_branding_block",
>       "admin_label" = @Translation("Site branding")
> ]))>>
> 
> 
> you don't need to split your annotation into many attributes. You should
> just adopt its syntax to become a valid PHP expression.
> This expression is not going to be evaluated. It's going to be just
> parsed into AST. and then you may traverse this AST and transform it
> into other data structures.
> The key idea of RFC was not to invite another language for meta-data,
> but use PHP language itself.

This is a good way to avoid handling a lot of issue, but what I am
afraid of is that with this solution, what would happen that people
start doing exactly that - inventing another languages for metadata. In
fact, that's exactly what the expression above does - it uses "=" as
named argument, and uses @ as special tag, not like PHP does. So it's in
fact mini-language using PHP's AST parser to tokenize its grammar, but
having separate semantics.

Maybe that's what we want to have here - freedom for everybody to invent
their own languages - but I fear the danger of fragmentation here and
also people implementing tons of slightly different incompatible parsers
for ASTs that are generated. We'd have Drupal attributes and Symphony
attributes and Doctrine attributes and Zend attributes and so on, and
each of them would have different semantics. Not sure this would be
good. But maybe it avoids arguing about the syntax now.

> we don't have fully constructed classes at compile time. Classes may be
> used during transformation from plain arrays and AST into application
> specific data structures.

We don't have classes but we do namespace resolution right? For
namespace resolution, you don't need to have the class actually present.
I don't think we need it for ::class either.

-- 
Stas Malyshev
smalyshev@gmail.com