Hello,
About your claims:
1. no conflicts? How? you import many annotations into one namespace,
there have to be conflicts. So it isn't different to (1)
2. This seems like avoid argument, why is it the most flexible?
3. How is hard validation possible for the example you have given, say
you load @Id. To not throw a fatal error when checking for
"Symfony\Component\Vaildator\Contraints\*" you have to do
class_exists($class, false). This would require every annotation using
library to require_once all annotations beforehand. Which Doctrine does
for performance optimization, but shouldn't really be a necessary
feature.
4. This is not an argument for this approach, first annotations on a
language level will have a considerably different syntax then docblocks
will ever have, so compatibility is not really an issue. Second
propablilty of annotations in core is almost void, Third, even if we get
annotations it is overconfident to claim this will be the most likely
implementation.
greetings,
Benjamin
On Tue, 19 Apr 2011 10:07:52 -0700 (PDT), Johannes wrote:
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 [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
