----- "Etienne Kneuss" <col...@php.net> wrote:
> ----- "Guilherme Blanco" <guilhermebla...@gmail.com> wrote:
>
> > @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.
>
> In what I suggest, there wouldn't even be named assignments (unless
> supported by PHP).
>
> The only special syntax for the outer annotation is by prefixing with
> "%" and avoiding the "new", but that's it.
>
> Even with that inconsistency it's still far more consistent with PHP
> as a whole IMO.
>
> >
> > 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.
>
> It's not about the specific separator, I'm just pointing out that even
> though @ is not available, we can also use other infix operator, to
> have something close to what we can find in other languages.
s,infix,prefix,
>
> >
> >
> > 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
