----- "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
