FAQ
Hi Guilherme,
On 4 November 2014 23:47, guilhermeblanco@gmail.com wrote:

Sorry, I forgot to add references to how we fixed emails handling. It got
split in 2 places:

- Initial root level annotation

https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L350

- Subsequent root level annotations

https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L631
I'm not sure if we need that sort of syntax and opinionated approach: I
like Benjamin's approach better, and it is also simpler and still very easy
to use even in our context (doctrine).

For example, this alternative approach perfectly fits the current
doctrine/annotations use-case:

use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Table;
use Doctrine\ORM\Mapping\Id;
use Doctrine\ORM\Mapping\GeneratedValue;
use Doctrine\ORM\Mapping\Column;

[Entity::class => []]
[Table::class => ['name' => 'foo_table']]
class Foo
{
     [Id::class => []]
     [GeneratedValue::class => [GeneratedValue::UUID]]
     [Column::class => ['name' => 'bar_column', 'type' => 'string']]
     private $bar;
}

I did nothing special here, just using plain old associative arrays and
built-in `::class` pseudo-constants: this leaves space for libraries that
do want to use annotations, but not the way doctrine/annotations does it
(calling the constructor of an annotation), and the annotations themselves
can still decide what to do with nested values.

No autoloading is going on, no code execution, nothing: plain and simple
arrays which may as well be used for phpdocumentor as well, if needed.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2019 Grokbase