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.
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).
> 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
