@Benjamin,
to 1) "unsolvable" conflicts, e.g. if there is a conflict you as the user
can always alias one of the imports
to 2) it is most flexible because it allows to drop the aliases if there is
no conflict, why keep them at all?
to 3) hard validation is possible because annotations need to be imported by
classes, if an annotation is not imported but used, then there is something
wrong (note that we can only make that assumption if the class has imported
at least something)
to 4) it is likely because it is very similar to PHP namespaces, and the
Java implementation of annotations; besides it is also compatible if PHP
adds reflection support for getting the PHP use statements as mentioned by
guilhermeblanco
@guilhermeblanco,
I have worked on an implementation a bit, and we would basically need a
pre-processing step which gathers the use-statements from the class doc
block before the "real" annotations could be read.
Johannes
On Tue, Apr 19, 2011 at 11:37 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> @Benjamin
>
> Not that large. When i introduced EntityNamespaces it was simple.
> The idea we could do is through a separate Namespaces per class, so
> just another HashMap is needed. =)
> The problem is when we could cleanup an already grabbed item.
>
> Cheers,
>
> On Tue, Apr 19, 2011 at 5:48 PM, Fabien Potencier
> <fabien.potenc...@symfony-project.com> wrote:
> > 3) looks better and simple enough as it reminds me of PHP namespaces.
> >
> > Fabien
> >
> > --
> > Fabien Potencier
> > Sensio CEO - Symfony lead developer
> > sensiolabs.com | symfony.com | fabien.potencier.org
> > Tél: +33 1 40 99 80 80
> >
> > On 4/19/11 7:07 PM, Johannes wrote:
> >>
> >> We have talked about this topic recently; now I want to sum up some of
> >> the solutions that were mentioned back then, and see what you think. I
> >> believe we need to find a better solution here than everyone setting
> >> up a different alias for his namespace, this is getting ugly really
> >> quickly.
> >>
> >> 1) Allow to register multiple namespaces for an alias
> >>
> >> Pros:
> >> - easy to implement
> >>
> >> Cons:
> >> - solves the problem only partially (all namespaces for an alias need
> >> to be registered in the same parser which is not always possible)
> >>
> >>
> >> 2) Allowing to declare aliases, and default namespace on a class-level
> >>
> >> /**
> >> * @annot:ns("Doctrine\ODM\MongoDB\Mapping", {
> >> * "validation"="Symfony\Component\Validator\Constraints"
> >> * })
> >> */
> >> class A { }
> >>
> >> Pros:
> >> - more flexibility than 1)
> >>
> >> Cons:
> >> - also cannot handle more than one namespace per alias with hard
> >> validation
> >> - harder to implement than 1)
> >>
> >>
> >> 3) Importing annotations that are used in the class
> >>
> >> /**
> >> * @use("Symfony\Component\Validator\Constraints\*")
> >> * @use("Doctrine\ODM\MongoDB\Mapping\*")
> >> * @use("Doctrine\ORM\Mapping\*", alias="orm")
> >> */
> >> class A {
> >> /**
> >> * @Id
> >> * @orm:Id
> >> * @NotBlank
> >> */
> >> private $name;
> >> }
> >>
> >> Pros:
> >> - works always (no unsolvable conflicts)
> >> - very flexible
> >> - hard validation is possible
> >> - probably best forward compatibility if annotations are ever
> >> implemented on language level
> >>
> >> Cons:
> >> - harder to implement than 1)
> >>
> >>
> >> Let me also add that IMO we should not pay particular attention to
> >> whether the solution can be merged back into doctrine-commons, or not.
> >> It would be great if it can be merged back, but it shouldn't be a must
> >> IMO.
> >>
> >> Thoughts?
> >>
> >> Kind regards,
> >> Johannes
> >>
> >
> > --
> > If you want to report a vulnerability issue on symfony, please send it to
> > security at symfony-project.com
> >
> > You received this message because you are subscribed to the Google
> > Groups "symfony developers" group.
> > To post to this group, send email to symfony-devs@googlegroups.com
> > To unsubscribe from this group, send email to
> > symfony-devs+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/symfony-devs?hl=en
> >
>
>
>
> --
> Guilherme Blanco
> Mobile: +55 (16) 9215-8480
> MSN: guilhermebla...@hotmail.com
> São Paulo - SP/Brazil
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to symfony-devs@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-devs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
