@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
