I agree with Benjamin - Why cant the standard just be the bundle name
for aliases for 3rd party bundles?
@SecurityExtraBundle, @FOSSomethingBundle ?
t
On Wed, Apr 20, 2011 at 08:33, Benjamin Eberlei <kont...@beberlei.de> wrote:
> 3.) How does \* constitute importing a specific class? How do you know what
> classes exist that haven't been autoloaded yet?
>
> I still don't get why this is such a problem rather then giving different
> annotation aliases per bundle as we give different names for EVERYTHING
> else.
>
> On Tue, 19 Apr 2011 23:50:44 +0200, Johannes Schmitt wrote:
>>
>> @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 [16]
>> 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
>>> wrote:
>>> > 3) looks better and simple enough as it reminds me of PHP
>>> namespaces.
>>> >
>>> > Fabien
>>> >
>>> > --
>>> > Fabien Potencier
>>> > Sensio CEO - Symfony lead developer
>>> > sensiolabs.com [2] | symfony.com [3] | fabien.potencier.org [4]
>>> > Tél: +33 1 40 99 80 80 [5]
>>> >
>>> > 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("DoctrineODMMongoDBMapping", {
>>> >> * "validation"="SymfonyComponentValidatorConstraints"
>>> >> * })
>>> >> */
>>> >> 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("SymfonyComponentValidatorConstraints*")
>>> >> * @use("DoctrineODMMongoDBMapping*")
>>> >> * @use("DoctrineORMMapping*", 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 [6]
>>> >
>>> > 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 [7]
>>> > To unsubscribe from this group, send email to
>>> > symfony-devs+unsubscr...@googlegroups.com [8]
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/symfony-devs?hl=en [9]
>>> >
>>>
>>> --
>>>
>>> Guilherme Blanco
>>> Mobile: +55 (16) 9215-8480 [10]
>>> MSN: guilhermebla...@hotmail.com [11]
>>> São Paulo - SP/Brazil
>>>
>>> --
>>>
>>> If you want to report a vulnerability issue on symfony, please send
>>> it to security at symfony-project.com [12]
>>>
>>> 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
>>> [13]
>>> To unsubscribe from this group, send email to
>>> symfony-devs+unsubscr...@googlegroups.com [14]
>>> For more options, visit this group at
>>> http://groups.google.com/group/symfony-devs?hl=en [15]
>>
>> --
>> 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 [18]
>>
>>
>> Links:
>> ------
>> [1] mailto:fabien.potenc...@symfony-project.com
>> [2] http://sensiolabs.com
>> [3] http://symfony.com
>> [4] http://fabien.potencier.org
>> [5] http://www.beberlei.de/tel:%2B33%201%2040%2099%2080%2080
>> [6] http://symfony-project.com
>> [7] mailto:symfony-devs@googlegroups.com
>> [8] mailto:symfony-devs%2bunsubscr...@googlegroups.com
>> [9] http://groups.google.com/group/symfony-devs?hl=en
>> [10] http://www.beberlei.de/tel:%2B55%20%2816%29%209215-8480
>> [11] mailto:guilhermebla...@hotmail.com
>> [12] http://symfony-project.com
>> [13] mailto:symfony-devs@googlegroups.com
>> [14] mailto:symfony-devs%2bunsubscr...@googlegroups.com
>> [15] http://groups.google.com/group/symfony-devs?hl=en
>> [16] mailto:guilhermebla...@gmail.com
>> [17] mailto:guilhermebla...@gmail.com
>> [18] 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
>
--
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
