I would like to point out that except (1) nothing is possible at all
with the Doctrine Annotations Parser without a heavy rewrite.
The problem is easily described:
Any method or variable block has no access to the context of classes.
If that would be done for every variable and method doc block you have
to parse the class header and add the context to the variable/method
parsing process.
While I understand your concern with wanting to fix the @extra issue i
am still wondering why not change the annotation prefixes to @security.
I doubt there will be a huge amount of annotations prefixes with future
bundles that might lead to clashes. additionally it would be trivial for
bundle implementors to make the prefix configurable on demand.
greetings,
Benjamin
On Tue, 19 Apr 2011 15:46:17 -0300, guilhermebla...@gmail.com wrote:
You all convinced me of (3), but I'd like to highlight an issue.
What would the Parser do if it finds same class name on different use
definitions?
Example:
File System:
Doctrine\Entity
MyApp\Entity
And then in class definition:
<?php
/**
* @use("Doctrine\*")
* @use("MyApp\*")
*
* @Entity
*/
class User { ... }
Should we do a lookup on all uses and then trigger an Exception if we
find a conflict (which would require us to attempt to load on every
namespace, and if more than one is loaded, throw exception)?
Also, I'd like to point out that AGAIN our language isn't powerful
enough to accomplish the correct implementation.
The "use" imports should be part of a currently unexistant
ReflectionNamespace.
We already have a feature enhancement request since RC...
http://bugs.php.net/bug.php?id=47794
By now, we could keep on ReflectionClass.
[]s,
On Tue, Apr 19, 2011 at 2:49 PM, Amal Raghav <amal.rag...@gmail.com>
wrote:
(3) is so perfect :)
On Apr 19, 10:16 pm, Bernhard Schussek <bschus...@gmail.com> wrote:
Hi Johannes,
Thanks for starting this discussion. This really is a problem right
now.
2011/4/19 Johannes <johannes.schmitt...@googlemail.com>:
> 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)
I'm in favor of this solution. It's very clear and doesn't produce
any
conflicts outside of the given file. The current way of having
predefine global prefixes just sucks when many people start using
(custom) annotations.
Bernhard
--
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
