Quantcast

Annotations: own implementation or Doctrine Commons'?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Annotations: own implementation or Doctrine Commons'?

Marco Pivetta
Hi everybody,

I'm posting to anticipate some of the discussion that will be brought up Wednesday at the meeting.

Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

So I came up with the idea of using Doctrine's annotations also for ZendFramework 2 (see http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html and https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations ).
I have already opened a pull request at https://github.com/zendframework/zf2/pull/1581 with the changes that would be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to make the parser of doctrine less strict at https://github.com/doctrine/common/pull/156.

My point is that there is absolutely no serialization that the current ZF2 implementation handles that cannot be reproduced with Doctrine's annotations syntax. Since (as brought up by Benjamin Eberlei) annotations are value object, we don't need an initialization logic for them either.
I've really been thinking for a couple of days about cases that couldn't be ported to doctrine annotations, and didn't find any for now. Also, the Doctrine annotations are being used since a couple of years ago in Flow3, Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's implementation.

So I'd like to ask you what you think of this idea, and if you think (and why) that we would need a separate format for annotations. These are the available options:

  1. Include `doctrine/common` as a dependency of `zendframework/zendframework` (speaking of composer.json), or more precisely of `zendframework/zend-code` (see my pull request on github)
  2. Copy the code from `doctrine/common` and adopt their format for annotations as part of ZF2's codebase
  3. Use the current implementation

I personally am for adopting #1, since I couldn't find any implementation that doesn't work also in Doctrine's annotations.

There has been some disagreement "because doctrine is forcing its own `standard`".
I don't think that makes any sense, since Doctrine simply has a working implementation that has been used over a couple of years without major problems and that is already adopted by the other framework that works best when mixed with ZendFramework 2 (yes, Symfony2).

I am not "advertising" Doctrine project here, I'm just trying to avoid a collision between two formats that actually do the exact same thing.

Please feel also free to comment on the Gist and the Pull Request, and look at how I changed the annotations to make them compatible with the form component (you will notice that the differences are quite small. Also, please let me know if you find use cases where Doctrine's annotations won't cover what ZF2's annotations do.

Thank you,


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

guilhermeblanco@gmail.com

Also the current Doctrine Annotations syntax is going to be supported in Netbeans 7.2, which will be released in 7 days

On Jun 24, 2012 12:32 PM, "Marco Pivetta" <[hidden email]> wrote:
Hi everybody,

I'm posting to anticipate some of the discussion that will be brought up Wednesday at the meeting.

Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

So I came up with the idea of using Doctrine's annotations also for ZendFramework 2 (see http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html and https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations ).
I have already opened a pull request at https://github.com/zendframework/zf2/pull/1581 with the changes that would be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to make the parser of doctrine less strict at https://github.com/doctrine/common/pull/156.

My point is that there is absolutely no serialization that the current ZF2 implementation handles that cannot be reproduced with Doctrine's annotations syntax. Since (as brought up by Benjamin Eberlei) annotations are value object, we don't need an initialization logic for them either.
I've really been thinking for a couple of days about cases that couldn't be ported to doctrine annotations, and didn't find any for now. Also, the Doctrine annotations are being used since a couple of years ago in Flow3, Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's implementation.

So I'd like to ask you what you think of this idea, and if you think (and why) that we would need a separate format for annotations. These are the available options:

  1. Include `doctrine/common` as a dependency of `zendframework/zendframework` (speaking of composer.json), or more precisely of `zendframework/zend-code` (see my pull request on github)
  2. Copy the code from `doctrine/common` and adopt their format for annotations as part of ZF2's codebase
  3. Use the current implementation

I personally am for adopting #1, since I couldn't find any implementation that doesn't work also in Doctrine's annotations.

There has been some disagreement "because doctrine is forcing its own `standard`".
I don't think that makes any sense, since Doctrine simply has a working implementation that has been used over a couple of years without major problems and that is already adopted by the other framework that works best when mixed with ZendFramework 2 (yes, Symfony2).

I am not "advertising" Doctrine project here, I'm just trying to avoid a collision between two formats that actually do the exact same thing.

Please feel also free to comment on the Gist and the Pull Request, and look at how I changed the annotations to make them compatible with the form component (you will notice that the differences are quite small. Also, please let me know if you find use cases where Doctrine's annotations won't cover what ZF2's annotations do.

Thank you,


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Sascha-Oliver Prolic
2012/6/24 [hidden email] <[hidden email]>:

> Also the current Doctrine Annotations syntax is going to be supported in
> Netbeans 7.2, which will be released in 7 days
>
> On Jun 24, 2012 12:32 PM, "Marco Pivetta" <[hidden email]> wrote:
>>
>> Hi everybody,
>>
>> I'm posting to anticipate some of the discussion that will be brought up
>> Wednesday at the meeting.
>>
>> Annotations are something that has been lying around in ZendFramework 2
>> for quite some time before we got to notice some of the problems they are
>> introducing.
>> Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while
>> working on forms.
>> Please refer to https://gist.github.com/2983803 for a list of examples of
>> collisions between the two implementations.
>>
>> So I came up with the idea of using Doctrine's annotations also for
>> ZendFramework 2 (see
>> http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html
>> and
>> https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations
>> ).
>> I have already opened a pull request at
>> https://github.com/zendframework/zf2/pull/1581 with the changes that would
>> be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to
>> make the parser of doctrine less strict at
>> https://github.com/doctrine/common/pull/156.
>>
>> My point is that there is absolutely no serialization that the current ZF2
>> implementation handles that cannot be reproduced with Doctrine's annotations
>> syntax. Since (as brought up by Benjamin Eberlei) annotations are value
>> object, we don't need an initialization logic for them either.
>> I've really been thinking for a couple of days about cases that couldn't
>> be ported to doctrine annotations, and didn't find any for now. Also, the
>> Doctrine annotations are being used since a couple of years ago in Flow3,
>> Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's
>> implementation.
>>
>> So I'd like to ask you what you think of this idea, and if you think (and
>> why) that we would need a separate format for annotations. These are the
>> available options:
>>
>> Include `doctrine/common` as a dependency of `zendframework/zendframework`
>> (speaking of composer.json), or more precisely of `zendframework/zend-code`
>> (see my pull request on github)
>> Copy the code from `doctrine/common` and adopt their format for
>> annotations as part of ZF2's codebase
>> Use the current implementation
>>
>> I personally am for adopting #1, since I couldn't find any implementation
>> that doesn't work also in Doctrine's annotations.
>>
>> There has been some disagreement "because doctrine is forcing its own
>> `standard`".
>> I don't think that makes any sense, since Doctrine simply has a working
>> implementation that has been used over a couple of years without major
>> problems and that is already adopted by the other framework that works best
>> when mixed with ZendFramework 2 (yes, Symfony2).
>>
>> I am not "advertising" Doctrine project here, I'm just trying to avoid a
>> collision between two formats that actually do the exact same thing.
>>
>> Please feel also free to comment on the Gist and the Pull Request, and
>> look at how I changed the annotations to make them compatible with the form
>> component (you will notice that the differences are quite small. Also,
>> please let me know if you find use cases where Doctrine's annotations won't
>> cover what ZF2's annotations do.
>>
>> Thank you,
>>
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://marco-pivetta.com
>>
>

+1 for Doctrine\Common. Having that dependency is not a bad thing, as
many would faulty suggest.

Best Regards

Sascha

--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Annotations: own implementation or Doctrine Commons'?

Roediger, Tim
In reply to this post by Marco Pivetta

+1 Doctrine annotations

 

I’d also prefer option 1 below.

 

Tim Roediger

 

From: Marco Pivetta [mailto:[hidden email]]
Sent: Monday, 25 June 2012 2:32 AM
To: Zend Framework Contributors
Subject: [zf-contributors] Annotations: own implementation or Doctrine Commons'?

 

Hi everybody,

I'm posting to anticipate some of the discussion that will be brought up Wednesday at the meeting.

Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

So I came up with the idea of using Doctrine's annotations also for ZendFramework 2 (see http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html and https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations ).
I have already opened a pull request at https://github.com/zendframework/zf2/pull/1581 with the changes that would be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to make the parser of doctrine less strict at https://github.com/doctrine/common/pull/156.

My point is that there is absolutely no serialization that the current ZF2 implementation handles that cannot be reproduced with Doctrine's annotations syntax. Since (as brought up by Benjamin Eberlei) annotations are value object, we don't need an initialization logic for them either.
I've really been thinking for a couple of days about cases that couldn't be ported to doctrine annotations, and didn't find any for now. Also, the Doctrine annotations are being used since a couple of years ago in Flow3, Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's implementation.

So I'd like to ask you what you think of this idea, and if you think (and why) that we would need a separate format for annotations. These are the available options:

  1. Include `doctrine/common` as a dependency of `zendframework/zendframework` (speaking of composer.json), or more precisely of `zendframework/zend-code` (see my pull request on github)
  2. Copy the code from `doctrine/common` and adopt their format for annotations as part of ZF2's codebase
  3. Use the current implementation

I personally am for adopting #1, since I couldn't find any implementation that doesn't work also in Doctrine's annotations.

There has been some disagreement "because doctrine is forcing its own `standard`".
I don't think that makes any sense, since Doctrine simply has a working implementation that has been used over a couple of years without major problems and that is already adopted by the other framework that works best when mixed with ZendFramework 2 (yes, Symfony2).

I am not "advertising" Doctrine project here, I'm just trying to avoid a collision between two formats that actually do the exact same thing.

Please feel also free to comment on the Gist and the Pull Request, and look at how I changed the annotations to make them compatible with the form component (you will notice that the differences are quite small. Also, please let me know if you find use cases where Doctrine's annotations won't cover what ZF2's annotations do.

Thank you,


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

David Muir-2
In reply to this post by guilhermeblanco@gmail.com
Can't confirm, but based on the docs, Eclipse also supports Doctrine's
annotations (Symfony2 plugin).

What about caching? Does using Doctrine's annotations require the use of
Doctrine's caching system?

Cheers,
David


On 25/06/12 02:52, [hidden email] wrote:
>
> Also the current Doctrine Annotations syntax is going to be supported
> in Netbeans 7.2, which will be released in 7 days
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

guilhermeblanco@gmail.com
Yes, it uses.

Doctrine Common is a small package that features relevant code that SHOULD be in PHP natively.
Collections, Cache and Annotations are useful packages you can find there.
Recently we just merged support for PHP Files as cache, which makes Annotations support more cool.


On Mon, Jun 25, 2012 at 12:10 AM, David Muir <[hidden email]> wrote:
Can't confirm, but based on the docs, Eclipse also supports Doctrine's annotations (Symfony2 plugin).

What about caching? Does using Doctrine's annotations require the use of Doctrine's caching system?

Cheers,
David



On 25/06/12 02:52, [hidden email] wrote:

Also the current Doctrine Annotations syntax is going to be supported in Netbeans 7.2, which will be released in 7 days







--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Marco Pivetta

Anyway, Caching is not required to use annotations ( again, see the PR )
On Jun 25, 2012 6:17 AM, "[hidden email]" <[hidden email]> wrote:
>
> Yes, it uses.
>
> Doctrine Common is a small package that features relevant code that SHOULD be in PHP natively.
> Collections, Cache and Annotations are useful packages you can find there.
> Recently we just merged support for PHP Files as cache, which makes Annotations support more cool.
>
>
>
> On Mon, Jun 25, 2012 at 12:10 AM, David Muir <[hidden email]> wrote:
>>
>> Can't confirm, but based on the docs, Eclipse also supports Doctrine's annotations (Symfony2 plugin).
>>
>> What about caching? Does using Doctrine's annotations require the use of Doctrine's caching system?
>>
>> Cheers,
>> David
>>
>>
>>
>> On 25/06/12 02:52, [hidden email] wrote:
>>>
>>>
>>> Also the current Doctrine Annotations syntax is going to be supported in Netbeans 7.2, which will be released in 7 days
>>>
>>>
>>
>>
>
>
>
> --
> Guilherme Blanco
> MSN: [hidden email]
> GTalk: guilhermeblanco
> Toronto - ON/Canada

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Jurian Sluiman
In reply to this post by Marco Pivetta
Hi Marco, 

Comments are inline :)

2012/6/24 Marco Pivetta <[hidden email]>
Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

Are you sure there are *collisions* of annotations in this code? I know Kyle wants to reduce the amount of annotations and therefore use one annotation to hint for multiple features (so one annotation means something to object-database mappers and form builders).

Both types of annotations use a namespace, imported at the top of the file. If both annotation readers are well designed, they should both be able to scan the file and retrieve the information it needs. So then no collisions would occur.
 
So I came up with the idea of using Doctrine's annotations also for ZendFramework 2 (see http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html and https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations ).

I don't follow your line of reasoning, so I can't conclude Zend Framework 2 needs to adopt Doctrine's annotations.
 
I have already opened a pull request at https://github.com/zendframework/zf2/pull/1581 with the changes that would be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to make the parser of doctrine less strict at https://github.com/doctrine/common/pull/156.

My point is that there is absolutely no serialization that the current ZF2 implementation handles that cannot be reproduced with Doctrine's annotations syntax. Since (as brought up by Benjamin Eberlei) annotations are value object, we don't need an initialization logic for them either.

I agree.
 
I've really been thinking for a couple of days about cases that couldn't be ported to doctrine annotations, and didn't find any for now. Also, the Doctrine annotations are being used since a couple of years ago in Flow3, Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's implementation.

I agree that annotation readers should be at least compatible. So you can use @ORM\OneToMany and have that parsed by the Zend Framework's annotation reader. But I think this does not immediately imply we need to drop Zend Framework's annotation reader.

Because both readers are different, I assume design decisions were different. We need to look at those differences before we can conclude if we need to switch to another reader. Again, I agree that annotations should be compatible, but if different design decisions have been made, you need to juxtapose those as well.
 
So I'd like to ask you what you think of this idea, and if you think (and why) that we would need a separate format for annotations. These are the available options:

  1. Include `doctrine/common` as a dependency of `zendframework/zendframework` (speaking of composer.json), or more precisely of `zendframework/zend-code` (see my pull request on github)
  2. Copy the code from `doctrine/common` and adopt their format for annotations as part of ZF2's codebase
  3. Use the current implementation
A separate format is undesirable, so for me #3 is not an option. That's all I can say :-)

I personally am for adopting #1, since I couldn't find any implementation that doesn't work also in Doctrine's annotations.

Again, don't look just at the outcome I'd say. I know Ralph is against adaptation of Doctrine's reader, but he probably has some arguments *why* and I am interested in those as well. 

There has been some disagreement "because doctrine is forcing its own `standard`".
I don't think that makes any sense, since Doctrine simply has a working implementation that has been used over a couple of years without major problems and that is already adopted by the other framework that works best when mixed with ZendFramework 2 (yes, Symfony2).

I am not "advertising" Doctrine project here, I'm just trying to avoid a collision between two formats that actually do the exact same thing.

A last comment I'd like to make is the effect of using Doctrine's annotation reader. The component is part of Doctrine\Common. In the thread is cache already mentioned, but Common holds more parts.

To be honest, the goal of Doctrine\Common seems to hold generic code *for the doctrine* project. There's code about cache, event managers, annotations, but also interfaces for persistence layers. And what's next? Probably some other code which could get abstracted out of Doctrine\Dbal, Doctirne\Orm or Doctrine\Odm. 

Please feel also free to comment on the Gist and the Pull Request, and look at how I changed the annotations to make them compatible with the form component (you will notice that the differences are quite small. Also, please let me know if you find use cases where Doctrine's annotations won't cover what ZF2's annotations do.

Thank you,


Marco Pivetta

Some months ago Ralph came up with Doctrine and/or Symfony developers to have "aliases" for php interfaces. So you could say the interface Zend\Code\Annotation\AnnotationInterface is equal to Doctrine\Common\Annotations\Annotation (NB. Please note annotations in Doctrine are *not* designed by contract, but based on a concrete class).

I'm just saying with my reply: look at the goal and then find the right solution. A common interface for annotations is the goal imho (and I agree upon that) but the adaptation of Doctrine's annotation reader is one solution. There might be others and this one is perhaps not the best option.
--
Jurian Sluiman
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Marco Pivetta
Hi Jurian,

Answers inline again :)

On 25 June 2012 09:38, Jurian Sluiman <[hidden email]> wrote:
Hi Marco, 

Comments are inline :)

2012/6/24 Marco Pivetta <[hidden email]>
Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

Are you sure there are *collisions* of annotations in this code? I know Kyle wants to reduce the amount of annotations and therefore use one annotation to hint for multiple features (so one annotation means something to object-database mappers and form builders).

Yes, Doctrine's parser `explodes` on stuff like `@Annotation\Name(some non valid value)`. This is surely something to be improved on Doctrine's side.
 

Both types of annotations use a namespace, imported at the top of the file. If both annotation readers are well designed, they should both be able to scan the file and retrieve the information it needs. So then no collisions would occur.

Yes, that for sure, but here it is Doctrine's fault being too strict. This should be improved on Doctrine's side.
 
I don't follow your line of reasoning, so I can't conclude Zend Framework 2 needs to adopt Doctrine's annotations.

It doesn't `need` to adopt them, since annotations aren't going to be the main feature in ZF2. My whole discussion starts from "not yet another format please" :)
 
 
I have already opened a pull request at https://github.com/zendframework/zf2/pull/1581 with the changes that would be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to make the parser of doctrine less strict at https://github.com/doctrine/common/pull/156.

My point is that there is absolutely no serialization that the current ZF2 implementation handles that cannot be reproduced with Doctrine's annotations syntax. Since (as brought up by Benjamin Eberlei) annotations are value object, we don't need an initialization logic for them either.

I agree.
 
I've really been thinking for a couple of days about cases that couldn't be ported to doctrine annotations, and didn't find any for now. Also, the Doctrine annotations are being used since a couple of years ago in Flow3, Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's implementation.

I agree that annotation readers should be at least compatible. So you can use @ORM\OneToMany and have that parsed by the Zend Framework's annotation reader. But I think this does not immediately imply we need to drop Zend Framework's annotation reader.

Because both readers are different, I assume design decisions were different. We need to look at those differences before we can conclude if we need to switch to another reader. Again, I agree that annotations should be compatible, but if different design decisions have been made, you need to juxtapose those as well.
 

The design decisions are different, but the result is almost the same, so it may come down to performance/memory only, and even with the performance/memory discussion in place, you don't want that parsing to happen at runtime. You will most probably want to cache annotations in any case (or anyway the result of `Zend\Code`'s elaboration)
 
So I'd like to ask you what you think of this idea, and if you think (and why) that we would need a separate format for annotations. These are the available options:

  1. Include `doctrine/common` as a dependency of `zendframework/zendframework` (speaking of composer.json), or more precisely of `zendframework/zend-code` (see my pull request on github)
  2. Copy the code from `doctrine/common` and adopt their format for annotations as part of ZF2's codebase
  3. Use the current implementation
A separate format is undesirable, so for me #3 is not an option. That's all I can say :-)

I personally am for adopting #1, since I couldn't find any implementation that doesn't work also in Doctrine's annotations.

Again, don't look just at the outcome I'd say. I know Ralph is against adaptation of Doctrine's reader, but he probably has some arguments *why* and I am interested in those as well. 

There has been some disagreement "because doctrine is forcing its own `standard`".
I don't think that makes any sense, since Doctrine simply has a working implementation that has been used over a couple of years without major problems and that is already adopted by the other framework that works best when mixed with ZendFramework 2 (yes, Symfony2).

I am not "advertising" Doctrine project here, I'm just trying to avoid a collision between two formats that actually do the exact same thing.

A last comment I'd like to make is the effect of using Doctrine's annotation reader. The component is part of Doctrine\Common. In the thread is cache already mentioned, but Common holds more parts.

To be honest, the goal of Doctrine\Common seems to hold generic code *for the doctrine* project. There's code about cache, event managers, annotations, but also interfaces for persistence layers. And what's next? Probably some other code which could get abstracted out of Doctrine\Dbal, Doctirne\Orm or Doctrine\Odm. 

That is something that has to be handled by doctrine and has already been taken into our plans. Currently, `Doctrine\Common` contains 4 big components that we should be able to split either into separate repositories or in separate composer packages, which would probably be something like `doctrine/annotations`, `doctrine/collections`, `doctrine/cache` and `doctrine/persistence`. The impact of including `doctrine/common` right now is not such a big issue right now, since the library is quite small. This is in my opinion an optimization that can be delayed right now, but it will happen for sure, and you and Ralph are not the first ones asking for this change.

Please feel also free to comment on the Gist and the Pull Request, and look at how I changed the annotations to make them compatible with the form component (you will notice that the differences are quite small. Also, please let me know if you find use cases where Doctrine's annotations won't cover what ZF2's annotations do.

Thank you,


Marco Pivetta

Some months ago Ralph came up with Doctrine and/or Symfony developers to have "aliases" for php interfaces. So you could say the interface Zend\Code\Annotation\AnnotationInterface is equal to Doctrine\Common\Annotations\Annotation (NB. Please note annotations in Doctrine are *not* designed by contract, but based on a concrete class).

I'm just saying with my reply: look at the goal and then find the right solution. A common interface for annotations is the goal imho (and I agree upon that) but the adaptation of Doctrine's annotation reader is one solution. There might be others and this one is perhaps not the best option.

I don't really think annotations need to implement an interface, but this doesn't mean that ZF2's annotations can't implement it. The only requirements for Doctrine annotations are:

  • being marked as /** @Annotation */ at class-level DocBlock
  • Having either a `public function __construct(array $data) { } or public attributes
These can perfectly live with implementing some annotation interface. I've also thought about having something different than initialization via constructor, but I couldn't really find an use case for that.

 
--
Jurian Sluiman



Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Annotations: own implementation or Doctrine Commons'?

Walter Tamboer
Hi,
 
Preferrably I'd like to use Doctrine's syntax since I'm using Doctrine itself already. It makes it easier to use and I prefer a syntax that is commonly known.
 
Having that said I am a full 100% against having a dependency to doctrine common. I feel that Zend Framework should act as a standalone library. If we start having dependencies to other libraries than why not use the EventManager of library X? Or the service manager of library Y? On top of that I feel that Doctrine's annotation manager is failing if it collides with other annotation formats.
 
Conclusion for me is that there should be an own implementation of an annotation parser in ZF. I think it would be fairly simple to create a pluggable lexer and parser implementation (hello service manager) in order to make the syntax configurable.
 
Regards,
 
Walter


From: [hidden email]
Date: Mon, 25 Jun 2012 10:03:02 +0200
To: [hidden email]
CC: [hidden email]
Subject: Re: [zf-contributors] Annotations: own implementation or Doctrine Commons'?

Hi Jurian,

Answers inline again :)

On 25 June 2012 09:38, Jurian Sluiman <[hidden email]> wrote:
Hi Marco, 

Comments are inline :)

2012/6/24 Marco Pivetta <[hidden email]>
Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

Are you sure there are *collisions* of annotations in this code? I know Kyle wants to reduce the amount of annotations and therefore use one annotation to hint for multiple features (so one annotation means something to object-database mappers and form builders).

Yes, Doctrine's parser `explodes` on stuff like `@Annotation\Name(some non valid value)`. This is surely something to be improved on Doctrine's side.
 

Both types of annotations use a namespace, imported at the top of the file. If both annotation readers are well designed, they should both be able to scan the file and retrieve the information it needs. So then no collisions would occur.

Yes, that for sure, but here it is Doctrine's fault being too strict. This should be improved on Doctrine's side.
 
I don't follow your line of reasoning, so I can't conclude Zend Framework 2 needs to adopt Doctrine's annotations.

It doesn't `need` to adopt them, since annotations aren't going to be the main feature in ZF2. My whole discussion starts from "not yet another format please" :)
 
 
I have already opened a pull request at https://github.com/zendframework/zf2/pull/1581 with the changes that would be required to do so, and there's an open PR by ezimuel (Enrico Zimuel) to make the parser of doctrine less strict at https://github.com/doctrine/common/pull/156.

My point is that there is absolutely no serialization that the current ZF2 implementation handles that cannot be reproduced with Doctrine's annotations syntax. Since (as brought up by Benjamin Eberlei) annotations are value object, we don't need an initialization logic for them either.

I agree.
 
I've really been thinking for a couple of days about cases that couldn't be ported to doctrine annotations, and didn't find any for now. Also, the Doctrine annotations are being used since a couple of years ago in Flow3, Symfony2 and Doctrine ORM/ODM/PHPCR, which then would collide with ZF2's implementation.

I agree that annotation readers should be at least compatible. So you can use @ORM\OneToMany and have that parsed by the Zend Framework's annotation reader. But I think this does not immediately imply we need to drop Zend Framework's annotation reader.

Because both readers are different, I assume design decisions were different. We need to look at those differences before we can conclude if we need to switch to another reader. Again, I agree that annotations should be compatible, but if different design decisions have been made, you need to juxtapose those as well.
 

The design decisions are different, but the result is almost the same, so it may come down to performance/memory only, and even with the performance/memory discussion in place, you don't want that parsing to happen at runtime. You will most probably want to cache annotations in any case (or anyway the result of `Zend\Code`'s elaboration)
 
So I'd like to ask you what you think of this idea, and if you think (and why) that we would need a separate format for annotations. These are the available options:

  1. Include `doctrine/common` as a dependency of `zendframework/zendframework` (speaking of composer.json), or more precisely of `zendframework/zend-code` (see my pull request on github)
  2. Copy the code from `doctrine/common` and adopt their format for annotations as part of ZF2's codebase
  3. Use the current implementation
A separate format is undesirable, so for me #3 is not an option. That's all I can say :-)
I personally am for adopting #1, since I couldn't find any implementation that doesn't work also in Doctrine's annotations.

Again, don't look just at the outcome I'd say. I know Ralph is against adaptation of Doctrine's reader, but he probably has some arguments *why* and I am interested in those as well. 

There has been some disagreement "because doctrine is forcing its own `standard`".
I don't think that makes any sense, since Doctrine simply has a working implementation that has been used over a couple of years without major problems and that is already adopted by the other framework that works best when mixed with ZendFramework 2 (yes, Symfony2).
I am not "advertising" Doctrine project here, I'm just trying to avoid a collision between two formats that actually do the exact same thing.
A last comment I'd like to make is the effect of using Doctrine's annotation reader. The component is part of Doctrine\Common. In the thread is cache already mentioned, but Common holds more parts.

To be honest, the goal of Doctrine\Common seems to hold generic code *for the doctrine* project. There's code about cache, event managers, annotations, but also interfaces for persistence layers. And what's next? Probably some other code which could get abstracted out of Doctrine\Dbal, Doctirne\Orm or Doctrine\Odm. 

That is something that has to be handled by doctrine and has already been taken into our plans. Currently, `Doctrine\Common` contains 4 big components that we should be able to split either into separate repositories or in separate composer packages, which would probably be something like `doctrine/annotations`, `doctrine/collections`, `doctrine/cache` and `doctrine/persistence`. The impact of including `doctrine/common` right now is not such a big issue right now, since the library is quite small. This is in my opinion an optimization that can be delayed right now, but it will happen for sure, and you and Ralph are not the first ones asking for this change.
Please feel also free to comment on the Gist and the Pull Request, and look at how I changed the annotations to make them compatible with the form component (you will notice that the differences are quite small. Also, please let me know if you find use cases where Doctrine's annotations won't cover what ZF2's annotations do.
Thank you,


Marco Pivetta

Some months ago Ralph came up with Doctrine and/or Symfony developers to have "aliases" for php interfaces. So you could say the interface Zend\Code\Annotation\AnnotationInterface is equal to Doctrine\Common\Annotations\Annotation (NB. Please note annotations in Doctrine are *not* designed by contract, but based on a concrete class).

I'm just saying with my reply: look at the goal and then find the right solution. A common interface for annotations is the goal imho (and I agree upon that) but the adaptation of Doctrine's annotation reader is one solution. There might be others and this one is perhaps not the best option.

I don't really think annotations need to implement an interface, but this doesn't mean that ZF2's annotations can't implement it. The only requirements for Doctrine annotations are:

  • being marked as /** @Annotation */ at class-level DocBlock
  • Having either a `public function __construct(array $data) { } or public attributes
These can perfectly live with implementing some annotation interface. I've also thought about having something different than initialization via constructor, but I couldn't really find an use case for that.

 
--
Jurian Sluiman



Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Marco Pivetta
Answers inline

On 25 June 2012 10:42, Walter Tamboer <[hidden email]> wrote:
Hi,
 
Preferrably I'd like to use Doctrine's syntax since I'm using Doctrine itself already. It makes it easier to use and I prefer a syntax that is commonly known.
 
Having that said I am a full 100% against having a dependency to doctrine common. I feel that Zend Framework should act as a standalone library. If we start having dependencies to other libraries than why not use the EventManager of library X? Or the service manager of library Y? On top of that I feel that Doctrine's annotation manager is failing if it collides with other annotation formats.

I'm actually using Symfony CLI, Symfony YAML and Doctrine Cache (instead of Zend\Cache) within my projects. Since we included composer in the workflow, you shouldn't (IMO) be thinking of Zend Framework as a "monolith" that has to be deployed in a single shot in your project. The dependency to `doctrine/common` would be for `zendframework/zend-code`, and since it is a requirement only for annotations (which aren't really something main in the framework) it could be put into the `suggest` section (see for example https://github.com/doctrine/doctrine2/blob/master/composer.json#L20 ). That dependency would be inherited by `zendframework/zendframework` anyway.
 
 
Conclusion for me is that there should be an own implementation of an annotation parser in ZF. I think it would be fairly simple to create a pluggable lexer and parser implementation (hello service manager) in order to make the syntax configurable.

In such a case I would first stick with the syntax we're used to, no?
 
 
Regards,
 
Walter

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

EvanDotPro
In reply to this post by Marco Pivetta

On Mon, Jun 25, 2012 at 1:03 AM, Marco Pivetta <[hidden email]> wrote:

2012/6/24 Marco Pivetta <[hidden email]>
Annotations are something that has been lying around in ZendFramework 2 for quite some time before we got to notice some of the problems they are introducing.
Those were accidentally discovered by SpiffyJr (Kyle Spraggs) while working on forms.
Please refer to https://gist.github.com/2983803 for a list of examples of collisions between the two implementations.

Are you sure there are *collisions* of annotations in this code? I know Kyle wants to reduce the amount of annotations and therefore use one annotation to hint for multiple features (so one annotation means something to object-database mappers and form builders).

Yes, Doctrine's parser `explodes` on stuff like `@Annotation\Name(some non valid value)`. This is surely something to be improved on Doctrine's side.
 

Both types of annotations use a namespace, imported at the top of the file. If both annotation readers are well designed, they should both be able to scan the file and retrieve the information it needs. So then no collisions would occur.

Yes, that for sure, but here it is Doctrine's fault being too strict. This should be improved on Doctrine's side.


Huh, it almost sounds like Doctrine should look into adopting Zend\Code's annotation parser design, as the above mentioned issues seem to be addressed, and as far as I can tell, it's already capable of supporting Doctrine's existing syntax, as the parsing is left open-ended. Just sayin'. ;)

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

mattcockayne
In reply to this post by Marco Pivetta
Some more comments inline

On Mon, Jun 25, 2012 at 9:54 AM, Marco Pivetta <[hidden email]> wrote:
Answers inline

On 25 June 2012 10:42, Walter Tamboer <[hidden email]> wrote:
Hi,
 
Preferrably I'd like to use Doctrine's syntax since I'm using Doctrine itself already. It makes it easier to use and I prefer a syntax that is commonly known.
 
Having that said I am a full 100% against having a dependency to doctrine common. I feel that Zend Framework should act as a standalone library. If we start having dependencies to other libraries than why not use the EventManager of library X? Or the service manager of library Y? On top of that I feel that Doctrine's annotation manager is failing if it collides with other annotation formats.

I'm actually using Symfony CLI, Symfony YAML and Doctrine Cache (instead of Zend\Cache) within my projects.
 
I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used
 
Since we included composer in the workflow, you shouldn't (IMO) be thinking of Zend Framework as a "monolith" that has to be deployed in a single shot in your project.

Your right it shouldn't be considered a monolith

The dependency to `doctrine/common` would be for `zendframework/zend-code`, and since it is a requirement only for annotations (which aren't really something main in the framework)

I would disagree with your statement that annotations are not something main in the framework. If I remember correctly annotations are used in DI, Form and DB (I could be wrong, feel free to correct me if I am) all of which are reasonably substantial components in their own right and it wouldn't surprise me to see annotations being featured more in other components over time.
 
it could be put into the `suggest` section (see for example https://github.com/doctrine/doctrine2/blob/master/composer.json#L20 ). That dependency would be inherited by `zendframework/zendframework` anyway.
 
 
Conclusion for me is that there should be an own implementation of an annotation parser in ZF. I think it would be fairly simple to create a pluggable lexer and parser implementation (hello service manager) in order to make the syntax configurable.

In such a case I would first stick with the syntax we're used to, no?
 
 
Regards,
 
Walter

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



--
Matt Cockayne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Marco Pivetta
@Evan, yes, but that just allows "yet another way" to do the same thing. Most (probably all) cases will just require the user to use JSON strings, such as

@Annotation\Name({"some": "content"})

... which is already supported by both parsers.
Do we really need to have users be able to write following?

@Annotation\Name(some content)

Yes, it is another choice, but what is the advantage in this second format? What does it represent that cannot be handled by following?

@Annotation\Name("some content")

Assuming Doctrine fixes its parser so that the second example's format is allowed/silently ignored, what is the point in having it? The annotation style picked by Doctrine currently tries to follow closely the JSRs (a quick overview at http://en.wikipedia.org/wiki/Java_annotation ). As far as I can see, there's a lot of YAGNI in the second approach. This doesn't mean that Doctrine doesn't have to fix its parser. That is surely a TODO, but yet, do we really need a new format?

On the other side, Doctrine's parser allows usage of following syntax:

@Annotation\Person(
    name=@Annotation\Name("Marco"),
    surname=@Annotation\Surname("Pivetta"),
    nickname=@Annotation\NickName("ocramius"),
    access=MyAclSystem::TYPE_ADMIN
)

Which produces an instance of "Person" populated with 3 other instances (Name, Surname, Nick) and the value of a constant. That is quite powerful and it would be an advantage to have support for it, and re-writing it would just be a waste of time (not to mention it has then to be maintained) :)

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 25 June 2012 11:18, Matt Cockayne <[hidden email]> wrote:
Some more comments inline

On Mon, Jun 25, 2012 at 9:54 AM, Marco Pivetta <[hidden email]> wrote:
Answers inline

On 25 June 2012 10:42, Walter Tamboer <[hidden email]> wrote:
Hi,
 
Preferrably I'd like to use Doctrine's syntax since I'm using Doctrine itself already. It makes it easier to use and I prefer a syntax that is commonly known.
 
Having that said I am a full 100% against having a dependency to doctrine common. I feel that Zend Framework should act as a standalone library. If we start having dependencies to other libraries than why not use the EventManager of library X? Or the service manager of library Y? On top of that I feel that Doctrine's annotation manager is failing if it collides with other annotation formats.

I'm actually using Symfony CLI, Symfony YAML and Doctrine Cache (instead of Zend\Cache) within my projects.
 
I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used
 
Since we included composer in the workflow, you shouldn't (IMO) be thinking of Zend Framework as a "monolith" that has to be deployed in a single shot in your project.

Your right it shouldn't be considered a monolith

The dependency to `doctrine/common` would be for `zendframework/zend-code`, and since it is a requirement only for annotations (which aren't really something main in the framework)

I would disagree with your statement that annotations are not something main in the framework. If I remember correctly annotations are used in DI, Form and DB (I could be wrong, feel free to correct me if I am) all of which are reasonably substantial components in their own right and it wouldn't surprise me to see annotations being featured more in other components over time.
 
it could be put into the `suggest` section (see for example https://github.com/doctrine/doctrine2/blob/master/composer.json#L20 ). That dependency would be inherited by `zendframework/zendframework` anyway.
 
 
Conclusion for me is that there should be an own implementation of an annotation parser in ZF. I think it would be fairly simple to create a pluggable lexer and parser implementation (hello service manager) in order to make the syntax configurable.

In such a case I would first stick with the syntax we're used to, no?
 
 
Regards,
 
Walter

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



--
Matt Cockayne

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Marco Pivetta
In reply to this post by mattcockayne
A dependency is _NOT_ a choice :)

I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

mattcockayne
lol...

I take your point.. what I was meaning is that of the components you mentioned

"Symfony CLI, Symfony YAML and Doctrine Cache"

You can use these by choice as Zend already provides perfectly acceptable components to perform the tasks that these components provide with the exception that Doctrine will be enforcing the Symfony components as a hard dependency which it does because of its close ties to Symfony.

On Mon, Jun 25, 2012 at 10:41 AM, Marco Pivetta <[hidden email]> wrote:
A dependency is _NOT_ a choice :)


I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



--
Matt Cockayne

Zucchi ! Digital Perfection
Managing Director

t: +44 (0) 161 435 6060
m: +44 (0) 843 557 1751
a: 26 Avon Rd / Cheadle / Cheshire / SK8 3LS



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Marco Pivetta
Nope, Doctrine Common has no dependency pointing to Symfony:
https://github.com/doctrine/common/blob/master/composer.json#L16

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 25 June 2012 12:01, Matt Cockayne <[hidden email]> wrote:
lol...

I take your point.. what I was meaning is that of the components you mentioned

"Symfony CLI, Symfony YAML and Doctrine Cache"

You can use these by choice as Zend already provides perfectly acceptable components to perform the tasks that these components provide with the exception that Doctrine will be enforcing the Symfony components as a hard dependency which it does because of its close ties to Symfony.

On Mon, Jun 25, 2012 at 10:41 AM, Marco Pivetta <[hidden email]> wrote:
A dependency is _NOT_ a choice :)


I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



--
Matt Cockayne

Zucchi ! Digital Perfection
Managing Director

t: <a href="tel:%2B44%20%280%29%20161%20435%206060" value="+441614356060" target="_blank">+44 (0) 161 435 6060
m: <a href="tel:%2B44%20%280%29%20843%20557%201751" value="+448435571751" target="_blank">+44 (0) 843 557 1751
a: 26 Avon Rd / Cheadle / Cheshire / SK8 3LS




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Maks3w
In reply to this post by Marco Pivetta

My opinion:

* I don't care if a feature come from the use of a third party library or not.

* But is true than doctrine-common has more stuff than only annotations. If Doctrine could split the annotations feature as an independent package I could see that with better eyes.

* I'm in favor of have the possibility of use different annotations from different providers as the same way some of us mix components from differents projects even sometimes having two components doing similar things at the same time. Maybe with a simple rules we can avoid any conflicts. Also the mayor part of Doctrine's annotations users use too PHPUnit's annotations, so the compatibility between different annotation managers is perfectly possible.

* The thing about IDEs support is for me clear. IDEs will implement what programmers do and not the programmer will implement what the IDE does.

Regards.


De: Marco Pivetta <[hidden email]>
Para: Matt Cockayne <[hidden email]>
CC: Walter Tamboer <[hidden email]>; [hidden email]; [hidden email]
Enviado: Lunes 25 de junio de 2012 11:41
Asunto: Re: [zf-contributors] Annotations: own implementation or Doctrine Commons'?

A dependency is _NOT_ a choice :)

I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

mattcockayne
In reply to this post by Marco Pivetta
Fair enough... its been a while since i dug around in doctrine... I do however seem to recall a requirement form the Symfont CLI and YAML somewhere... maye have been back in the Doctrine 1.2 days?

My point still stands that you are using those components by choice rather than by the dictates of any framework

On Mon, Jun 25, 2012 at 11:02 AM, Marco Pivetta <[hidden email]> wrote:
Nope, Doctrine Common has no dependency pointing to Symfony:
https://github.com/doctrine/common/blob/master/composer.json#L16


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 25 June 2012 12:01, Matt Cockayne <[hidden email]> wrote:
lol...

I take your point.. what I was meaning is that of the components you mentioned

"Symfony CLI, Symfony YAML and Doctrine Cache"

You can use these by choice as Zend already provides perfectly acceptable components to perform the tasks that these components provide with the exception that Doctrine will be enforcing the Symfony components as a hard dependency which it does because of its close ties to Symfony.

On Mon, Jun 25, 2012 at 10:41 AM, Marco Pivetta <[hidden email]> wrote:
A dependency is _NOT_ a choice :)


I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



--
Matt Cockayne

Zucchi ! Digital Perfection
Managing Director

t: <a href="tel:%2B44%20%280%29%20161%20435%206060" value="+441614356060" target="_blank">+44 (0) 161 435 6060
m: <a href="tel:%2B44%20%280%29%20843%20557%201751" value="+448435571751" target="_blank">+44 (0) 843 557 1751
a: 26 Avon Rd / Cheadle / Cheshire / SK8 3LS







--
Matt Cockayne

Zucchi ! Digital Perfection
Managing Director

t: +44 (0) 161 435 6060
m: +44 (0) 843 557 1751
a: 26 Avon Rd / Cheadle / Cheshire / SK8 3LS



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations: own implementation or Doctrine Commons'?

Fernando Andre
Hello,

Sorry for barging in on the discussion... But have these questions been raised about Zend\DI or Zend event manager , couldn't zf2 use the components from Symfony in that case?

Best regards,

On Mon, Jun 25, 2012 at 11:05 AM, Matt Cockayne <[hidden email]> wrote:
Fair enough... its been a while since i dug around in doctrine... I do however seem to recall a requirement form the Symfont CLI and YAML somewhere... maye have been back in the Doctrine 1.2 days?

My point still stands that you are using those components by choice rather than by the dictates of any framework


On Mon, Jun 25, 2012 at 11:02 AM, Marco Pivetta <[hidden email]> wrote:
Nope, Doctrine Common has no dependency pointing to Symfony:
https://github.com/doctrine/common/blob/master/composer.json#L16


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 25 June 2012 12:01, Matt Cockayne <[hidden email]> wrote:
lol...

I take your point.. what I was meaning is that of the components you mentioned

"Symfony CLI, Symfony YAML and Doctrine Cache"

You can use these by choice as Zend already provides perfectly acceptable components to perform the tasks that these components provide with the exception that Doctrine will be enforcing the Symfony components as a hard dependency which it does because of its close ties to Symfony.

On Mon, Jun 25, 2012 at 10:41 AM, Marco Pivetta <[hidden email]> wrote:
A dependency is _NOT_ a choice :)


I too use some of these and tend to mix and match my frameworks in the same way... however this is by my own choice and not dictated by any of the tools used


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



--
Matt Cockayne

Zucchi ! Digital Perfection
Managing Director

t: <a href="tel:%2B44%20%280%29%20161%20435%206060" value="+441614356060" target="_blank">+44 (0) 161 435 6060
m: <a href="tel:%2B44%20%280%29%20843%20557%201751" value="+448435571751" target="_blank">+44 (0) 843 557 1751
a: 26 Avon Rd / Cheadle / Cheshire / SK8 3LS







--
Matt Cockayne

Zucchi ! Digital Perfection
Managing Director

t: <a href="tel:%2B44%20%280%29%20161%20435%206060" value="+441614356060" target="_blank">+44 (0) 161 435 6060
m: <a href="tel:%2B44%20%280%29%20843%20557%201751" value="+448435571751" target="_blank">+44 (0) 843 557 1751
a: 26 Avon Rd / Cheadle / Cheshire / SK8 3LS




12
Loading...