@Christian:
Placing items on constructor may be valid at first glance, but it
would break class inheritance (constructor prototype).
So, that's why this idea was dropped.
@Etienne:
How would it work with nested Annotations?
%Foo(%Bar(type=%Woo))
If you consider just PHP after it, the correct would be:
%Foo(new Bar(type=new Woo()))
It seems not consistent to me.
I think the separator is not an issue to be accepted/not accepted.
Please just don't start ANOTHER 6 months discussion just to choose a
new separator.
On Wed, Aug 25, 2010 at 6:29 PM, Etienne Kneuss <col...@php.net> wrote:
>
> ----- "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.
>
> 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
>
>
--
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
