----- "Benjamin Eberlei" <[email protected]> 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
> <[email protected]> wrote:
> > On Thu, 26 Aug 2010 11:17:33 +0200, Benjamin Eberlei
> <[email protected]>
> > 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
