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 <[email protected]> wrote:
> (3) is so perfect :)
>
> On Apr 19, 10:16 pm, Bernhard Schussek <[email protected]> wrote:
>> Hi Johannes,
>>
>> Thanks for starting this discussion. This really is a problem right now.
>>
>> 2011/4/19 Johannes <[email protected]>:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > 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 [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
>
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: [email protected]
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 [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
