Hi Stas,
this type of annotations cannot be used as PHPDoc annotations due its
different syntax. In other languages like Java, C# or AS3 annotations
are an independent language construct and I think in PHP it should be
the same. I dont know how many non-performant user-land
implementations(hacks), with different syntaxes and concepts, exists in
the meantime. So I think it is time for a consistent syntax in the PHP
core.
I see your concerns about the inconsistency in the syntax, so here are
my thoughts how we can avoid this.
1. In Java annotations are a special type of an interface. But due the
lack of type hinting for scalar values we cannot use this construct,
because we cannot put some validation logic in an interface. My proposal
is to create a new "annotation" type. This type should have the same
rules as a class and should contain all features proposed in the
ReflectionAnnotation class. With this construct it should be possible to
use named or unnamed parameters for an annotation.
annotation URL {
public $url;
public $title;
public $target;
public function __construct($url, $title, $target = 'self') {
}
}
[URL('http://www.php.net', <http://www.php.net%27,> 'PHP', 'blank')] or
[URL('http://www.php.net', <http://www.php.net%27,> 'PHP')] or
[URL('url' = 'http://www.php.net', <http://www.php.net%27,> 'name' = 'PHP',
'target' = 'blank')]
With this new type there exists a new language construct which doesn't
overlap with the class construct. So it is possible to use its own
instantiation syntax.
2. The syntax for arrays should be the same as in PHP. So we can use the
[] as annotation separator. When we allow expressions in the form
Annotation(array('value' => 4 %2)) or Annotation(array('value' =>
!MY_CONSTANT)) which I think is a valid construct, then we cannot use
the ! or % as annotation separator.
3. For the consistency with named parameters there exists 2
possibilities. Either we implement named parameters in the PHP core or
named parameters are an exception for annotations.
I think with this changes we have a separate language construct like
traits, which does allow a new syntax.
Greetings,
Christian
Am 12.09.2010 00:48, schrieb Stas Malyshev:
> Hi!
>
>> It seems that there is a misunderstanding about the goals of the
>> annotations. They are not meant to be read by human being
>> (javadoc/phpdoc/etc. are) but to be parsed automatically to be used
>> for services.
>
> If it's for services/phpdoc, why can't it be part of phpdoc?
>
> I see here a whole new language syntax being invented, complete with
> nested constructs, new instantiation syntax, new argument parsing
> rules and what not. All that while tiniest attempts on introducing
> syntax sugar were consistently rejected. But here we have sub-section
> of language with totally different rules - PHP has no named
> parameters, but annotations have them, PHP has no array/instantiation
> shortcut syntax, but annotations have it, etc. Please understand, I'm
> not objecting to a particular detail of syntax - I'm objecting to the
> fact that the design of the language appears to be guided by a random
> whim.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
