Through aliasing via use is a better approach, I forgot about it.
But this still need to be implemented. Currently it doesn't handle
aliased namespaces too.
Related to instantiation per demand, it is true that can be optimized
to only instantiate things once.
As off array X objects, no matter which implementation we decide, user
will have to validate his own.
The difference we're conflicting is between validate using PHP parser
(using already existent features) or leave to user build his own.
Example:
[Foo(name="value")]
Objects: Unknown property 'name' on class 'Foo'
Array: ... if user don't validate it, no error ...
Also, using objects instead of array would allow users to build even
more complex behaviors, just like known Java frameworks does.
I'm not here to compare languages, but this is one of the good things
I see on another language.
Cheers,
On Thu, Aug 26, 2010 at 10:54 AM, Etienne Kneuss <col...@php.net> wrote:
> Test, sorry for the noise.
>
>
> On Aug 26 13:56:09, Etienne Kneuss wrote:
>>
>> ----- "Benjamin Eberlei" <kont...@beberlei.de> wrote:
>>
>> > That is true, arrays dont allow for aliasing of any kind if
>> > annotations
>> > have different meaning in different frameworks.
>> > With arrays you can at least use the one annotation for different
>> > purposes
>> > as long as these purposes don't define the same keys.
>> >
>> > With Objects however you always need aliasing. PHPUnit will want to
>> > have a
>> > PHPUnit_Annotation_ExpectedException class, not an ExceptionException
>> > class
>> > only. However nobody would want to write:
>> >
>> > [PHPUnit_Annotation_ExpectedException]
>> >
>> > So when including PHPUnit, the annotation classes would probably
>> > register
>> > themselves as alias. Using a prefix for the aliasing begs the question
>> > of
>> > how to find the real class, if you have 2 or more aliases defined.
>> > Iterate
>> > over them and check for existance?
>> >
>> > [ExpectedException] with many alises could be for example
>> > PHPUnit_Annotation_ExpectedException, or
>> > Doctrine\ORM\Mapping\ExceptedException or
>> > Symfony\Framework\Form\Annotation\ExpectedException.
>> >
>> > This sounds pretty expensive to me. So its probably better to have a
>> > map
>> > of alias => classname. But this is adding quite some management
>> > overhead,
>> > i.e. you need methods:
>> >
>> > ReflectionAnnotation::registerAlias($alias, $className);
>> > ReflectionAnnotation::hasAlias($alias);
>> > ReflectionAnnotation::getAliases();
>> > ReflectionAnnotation::getAliasClass($alias);
>> > ReflectionAnnotation::getAliasFor($className);
>> >
>> > Now say you have a library X with an Annotation aliased Bar (and you
>> > also
>> > use Framework Y with Annotation aliaased Bar).
>> >
>> > [Bar]
>> > class Foo
>> > {
>> >
>> > }
>>
>> I don't understand why aliasing of class names suddenly becomes an issue, we
>> now have namespaces which allow aliases.
>>
>> use NS\To\MyAnnotation as MyAnnot;
>>
>> [MyAnnot]
>> class Foo {
>>
>> }
>>
>> there is no need to have this aliasing mechanism at runtime as it will only
>> add more inconsistency to the plate.
>>
>> Best,
>>
>> >
>> > You call inside your library:
>> >
>> > $cls = new ReflectionClass($className);
>> > $annotations = $cls->getAnnotations();
>> >
>> > What will happen if:
>> >
>> > 1. The annotation classes are not loaded yet.
>> > 2. Only the annotation classes of your library are loaded.
>> > 3. Both annotation classes are loaded.
>> >
>> > On Thu, 26 Aug 2010 13:12:13 +0200, Christian Kaps
>> > <christian.k...@mohiva.com> wrote:
>> > > On Thu, 26 Aug 2010 11:17:33 +0200, Benjamin Eberlei
>> > <kont...@beberlei.de>
>> > > wrote:
>> > >> Hey,
>> > >>
>> > >> 3.
>> > >> Ok that point may be relevant, but there is also a semantically
>> > nice
>> > and
>> > >> simple solution:
>> > >>
>> > >> array('JoinTable' => array(
>> > >> 'name' => 'users_phonenumbers',
>> > >> 'joinColumns' => array(
>> > >> 0 => array('JoinColumn' => array('name' => 'user_id',
>> > >> 'referencedColumnName => 'id')),
>> > >> 1 => array('JoinColumn' => array('name' => 'user_id',
>> > >> 'referencedColumnName => 'id')),
>> > >> )
>> > >> ));
>> > >>
>> > >
>> > > [JoinTable(
>> > > name="users_phonenumbers",
>> > > joinColumns={
>> > > {JoinColumn={name="user_id", referencedColumnName="id"}},
>> > > {JoinColumn={name="user_id", referencedColumnName="id"}}
>> > > }
>> > > )]
>> > >
>> > > I think this gives you the same array structure as in your example
>> > but
>> > it
>> > > uses no nested annotations.
>> > >
>> > >>
>> > >> 5. You already mentioned further extensions with aliasing class
>> > names
>> > to
>> > >> "shorten"
>> > >> the annotations specification. However i see several problems with
>> > that:
>> > >>
>> > >> a.) It adds more code
>> > >> b.) Classes/Methods/Functions/Properties that have annotations of
>> > > multiple
>> > >> annotation libraries
>> > >> will cause pain with loading or autoloading of the necessary
>> > annotation
>> > >> classes.
>> > >> c.) What happens if an annotation has no corresponding class?
>> > >>
>> > >
>> > > You write that the developers should implement her complex class
>> > based
>> > > solution in userland. How would you handle aliasing for classes
>> > there?
>> > > Anywhere I must define the alias or the namespace of the annotation
>> > class,
>> > > otherwise I must register all annotations(annotation name => fully
>> > > qualified class name) used in my application before using them.
>> > Using
>> > > annotations from different frameworks with the same name makes this
>> > a
>> > pain.
>> > >
>> > > Greetings,
>> > > Christian
>> >
>> > --
>> > 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
>>
>
> --
> 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
