The constructor is called when you call the getAnnotations() or
getAnnotation() methods.
The current implementation basically do :
- At compile time you store all the data in a HashTable structure like
any other structure, class, method, properties...
- On execution time it does nothing unless you call getAnnotion or
getAnnotations. In this case it will just build Annotation objects
using the data stored in the previous hashTable.
Ex :
[Foo("bar", baz = "hello world"]
class Test {}
When you call getAnnotation('foo') it will just call
Foo::__construct(array('value' => 'bar', 'baz' => 'hello world'));
So there is no overhead on the execution time even if you have
annotations in your code.
Pierrick
2010/8/25 Etienne Kneuss <col...@php.net>:
>
> ----- "Pierrick Charron" <pierr...@webstart.fr> wrote:
>
>> 2010/8/25 Etienne Kneuss <col...@php.net>:
>> >
>> > ----- "Guilherme Blanco" <guilhermebla...@gmail.com> wrote:
>> >
>> >> Hi Etiene,
>> >>
>> >>
>> >> AliasedName is not implemented yet, but I added in RFC as one of
>> the
>> >> first enhancements to be done.
>> >> The purpose of it is to reduce the over-typing needed to
>> instantiate
>> >> namespaced classes.
>> >>
>> >> Here is the first idea:
>> >>
>> >> ReflectionAnnotation::addNamespaceAlias('Doctrine',
>> >> 'Doctrine\ORM\Mapping');
>> >>
>> >> [Doctrine:Entity]
>> >>
>> >> would be the same to
>> >>
>> >> [\Doctrine\ORM\Mapping\Entity]
>> >>
>> >>
>> >> The syntax can be changed, but there're some concerns to be made.
>> >>
>> >
>> > The problem that I see with this proposal is that it introduce a lot
>> of
>> > new syntax and rules, that not only are inconsistent with the
>> existing
>> > ones, but quite confusing.
>> >
>> >
>> > What I'm wondering is why can't we simply have the following simple
>> syntax:
>> >
>> > %MyAnnotation
>> >
>> > or
>> >
>> > %MyAnnotation(expr, ...)
>> >
>> > My Annotation would be the classref, instanciated as annotation.
>> > expr would be _any_ PHP expression. We could decide when to
>> actually
>> > execute the code, but I guess at the time of the class definition
>> would
>> > be ok.
>>
>> In the current implementation all the HashTable *annotation structure
>> is filled at compile time. You can then cache it into APC (not yet
>> done but i will work on it). So if you're using annotations you don't
>> have any overhead in the execution since everything is already stored
>> in memory.
>
> That strikes me as odd, what about:
>
> class Foo extends ReflectionAnnotation {
> public $foo;
>
> public function __construct() {
> $this->foo = 2;
> }
> }
>
> [Foo]
> class MyClass{}
>
> What is the value for the annotation's foo ?
> And when do you (if you do) call the constructor?
>
>>
>> Furthermore, since annotations are metadata related to class,
>> functions etc... You should just have to use variables that are
>> static
>> like const do (and everything can be done at compile time).
>
> Yes, and this is quite a painful language "feature". Lots of people,
> me included, are annoyed by the fact that default values lack proper
> expressions.
>
>>
>> > That way, we only introduce this "%" syntax, the rest is pure old
>> PHP.
>> > Note that "%" is using as an infix operator here, so it should not
>> > conflict with the existing grammar.
>> >
>> > To me, it looks _way_ easier to use, it might be a tad bit harder
>> to
>> > implement though.
>> >
>> >> Q1 - Why not use array() instead of {} ?
>> >>
>> >> The parser would consider array() as an Annotation and would
>> attempt
>> >> to instantiate it. Also, it's not so verbose do have:
>> >>
>> >> [Documentation(array("author" => "Guilherme Blanco", "age" =>
>> 26))]
>> >>
>> >> Where it could be simplified to:
>> >>
>> >> [Documentation({"author" = "Guilherme Blanco", "age" = 26})]
>> >>
>> >>
>> >> Q2- Why some keys are defined as string and others as identifiers?
>> >>
>> >> The reason of the existance to identifiers are for properties of
>> >> Annotation class, whereas key strings are used for array
>> denotation.
>> >>
>> >>
>> >> Q3- Why not use plain arrays as Annotations?
>> >>
>> >> This would lead to a simplified EBNF, yes... but also would lead
>> to
>> >> the lack of validation of keys, and would make Annotations accept
>> >> anything that may/may not have a meaning.
>> >> One of the main problems that PHP has is the lack of
>> standardization;
>> >> this is one the things we tried to achieve on this implementation.
>> >> Also, more and more PHP OO is not an optional thing. I know many
>> >> projects like Drupal/Wordpress are built around functional
>> paradigm;
>> >> but at the same time, I see no real use case to use Annotations on
>> >> functions, although we implemented this support. So... I still
>> don't
>> >> see reasonable arguments that would justify a change to arrays.
>> >>
>> >>
>> >> Q4- What are the possible enhancements to be made around it?
>> >>
>> >> I already added the AliasedName, mainly because I'm feeling
>> necessity
>> >> for it already.
>> >> Another one is to send the Reflector instance in Annotation
>> >> constructor, allowing then a possible userland validation. One
>> good
>> >> example:
>> >>
>> >> PHPUnit's ExpectedException is only valid for methods. So, a
>> possible
>> >> implementation:
>> >>
>> >> namespace PHPUnit;
>> >>
>> >> class ExpectedException extends \ReflectionAnnotation {
>> >> public function __construct(\Reflector $instance, array
>> $values)
>> >> {
>> >> if ( ! ($instance intanceof \ReflectionMethod) {
>> >> throw new Exception('ExpectedException is only allowed
>> in
>> >> method's scope.');
>> >> }
>> >> parent::__construct($instance, $values);
>> >> }
>> >> }
>> >>
>> >>
>> >> Q5- Annotations separator?
>> >>
>> >> Since we cannot use @, we picked from known possibilities of
>> >> namespace
>> >> separator and also programming languages that have similar
>> support.
>> >> The easiest I found is C#, which is the one we got it.
>> >>
>> >>
>> >>
>> >>
>> >> Any other questions?
>> >>
>> >> On Wed, Aug 25, 2010 at 1:04 PM, Pierrick Charron
>> >> <pierr...@webstart.fr> wrote:
>> >> > Hi Etienne,
>> >> >
>> >> > 2010/8/25 Etienne Kneuss <col...@php.net>:
>> >> >> On Aug 25 8:56:53, Pierrick Charron wrote:
>> >> >>> Hello PHP Internals!
>> >> >>>
>> >> >>> Recently a RFC was included on the PHP Wiki[1].
>> >> >>> I know there've been a lot of buzz related to PHP 5.4, but this
>> is
>> >> not
>> >> >>> the subject of this email.
>> >> >>>
>> >> >>> I'm here to propose a new feature in PHP: Annotations.
>> >> >>> A patch is already available with 54 tests for the moment[2].
>> >> >>>
>> >> >>> I worked together with Guilherme Blanco to make this support
>> >> happen in
>> >> >>> a fresh PHP SVN trunk checkout.
>> >> >>> Please review, comment and provide feedback! I think it's a
>> very
>> >> >>> useful support and may benefit users a lot.
>> >> >>>
>> >> >>> [1] http://wiki.php.net/rfc/annotations
>> >> >>> [2] http://www.adoy.net/php/Annotations.diff
>> >> >>
>> >> >> Quite interresting RFC! However, I've a few concerns/questions:
>> >> >>
>> >> >> 1) The new limitted syntax (esp. the field assignation). IMO
>> this
>> >> should
>> >> >> be extended to support more/all expressions.
>> >> >
>> >> > What kind of syntax would you like to add ? Right now you can
>> add
>> >> > common static variables, array and Annotations.
>> >> >
>> >> >>
>> >> >> 2) How does it create the annotation? will it call __construct?
>> If
>> >> so,
>> >> >> Foo("asd") should defeinitely map to a constructor call, and
>> the
>> >> field
>> >> >> assignation should be discarded unless we have named
>> parameters.
>> >> >
>> >> > Since php does not support named parameter the __construct is
>> >> called
>> >> > with an array as parameter
>> >> > [Foo("bar", baz="baz)]
>> >> > will call __construct(array("value" => "bar", "baz" => "baz));
>> >> >
>> >> >>
>> >> >> 3) What is the purpose of an aliased name?
>> >> >
>> >> > Aliased name ?
>> >> >
>> >> >>
>> >> >> Best,
>> >> >>
>> >> >>>
>> >> >>> Regards,
>> >> >>> Pierrick
>> >> >>>
>> >> >>> (Sorry if you receive this message twice but it looks like I
>> have
>> >> >>> problems with the ML)
>> >> >>>
>> >> >>> --
>> >> >>> PHP Internals - PHP Runtime Development Mailing List
>> >> >>> To unsubscribe, visit: http://www.php.net/unsub.php
>> >> >>>
>> >> >>
>> >> >> --
>> >> >> Etienne Kneuss
>> >> >>
>> >> >
>> >> > --
>> >> > PHP Internals - PHP Runtime Development Mailing List
>> >> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Guilherme Blanco
>> >> Mobile: +55 (16) 9215-8480
>> >> MSN: guilhermebla...@hotmail.com
>> >> São Paulo - SP/Brazil
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
