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
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
