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, [email protected] [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
[email protected] [7]
> To unsubscribe from this group, send email to
> [email protected] [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: [email protected] [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 [email protected]
[13]
To unsubscribe from this group, send email to
[email protected] [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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en [18]
Links:
------
[1] mailto:[email protected]
[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:[email protected]
[8] mailto:symfony-devs%[email protected]
[9] http://groups.google.com/group/symfony-devs?hl=en
[10] http://www.beberlei.de/tel:%2B55%20%2816%29%209215-8480
[11] mailto:[email protected]
[12] http://symfony-project.com
[13] mailto:[email protected]
[14] mailto:symfony-devs%[email protected]
[15] http://groups.google.com/group/symfony-devs?hl=en
[16] mailto:[email protected]
[17] mailto:[email protected]
[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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
