DDC-403: [Patch] Allow merging of ArrayCollection and other Collections #499

Closed
opened 2026-01-22 12:40:31 +01:00 by admin · 9 comments
Owner

Originally created by @doctrinebot on GitHub (Mar 10, 2010).

Jira issue originally created by user shurakai:

The attached patch adds the following functionality:

A method "merge" is added to ArrayCollection that takes a Collection as an argument and merges it into the current collection. This could be helpful when dealing with Collections.

UnitTests

Originally created by @doctrinebot on GitHub (Mar 10, 2010). Jira issue originally created by user shurakai: The attached patch adds the following functionality: # A method "merge" is added to ArrayCollection that takes a Collection as an argument and merges it into the current collection. This could be helpful when dealing with Collections. # UnitTests
admin added the Improvement label 2026-01-22 12:40:31 +01:00
admin closed this issue 2026-01-22 12:40:32 +01:00
Author
Owner

@doctrinebot commented on GitHub (Mar 11, 2010):

Comment created by @guilhermeblanco:

Hi Christian,

I'm not against to apply this, but it must be a generic solution.
If this will be merged in ArrayCollection, it should also be implemented in PersistentCollection (which is non-trivial).

Can you try to update the patch (and also include the prototype in the Collection interface)?

Cheers,

@doctrinebot commented on GitHub (Mar 11, 2010): Comment created by @guilhermeblanco: Hi Christian, I'm not against to apply this, but it must be a generic solution. If this will be merged in ArrayCollection, it should also be implemented in PersistentCollection (which is non-trivial). Can you try to update the patch (and also include the prototype in the Collection interface)? Cheers,
Author
Owner

@doctrinebot commented on GitHub (Mar 12, 2010):

Comment created by romanb:

I am very reluctant to adding new collection methods. As Guilherme mentioned this always means extending the Collection interface as well as adjusting PersistentCollection, thus every new method adds noticable code bloat. merge() is not something you usually find on a collection I think and its easy to do in userland. The Collection interface should remain minimal.

@doctrinebot commented on GitHub (Mar 12, 2010): Comment created by romanb: I am very reluctant to adding new collection methods. As Guilherme mentioned this always means extending the Collection interface as well as adjusting PersistentCollection, thus every new method adds noticable code bloat. merge() is not something you usually find on a collection I think and its easy to do in userland. The Collection interface should remain minimal.
Author
Owner

@doctrinebot commented on GitHub (Mar 12, 2010):

Comment created by romanb:

I think merge() would be the same as this:

foreach ($collB as $key => $element) { $collA->set($key, $element); }

Would it make sense to provide addAll/setAll methods? setAll would basically be the same as merge and both could easily be implemented since they can be implemented in terms of add() and set(), so change-tracking and lazy-loading is already taken care of.
However, these new methods would of course only be a minor convenience.

@doctrinebot commented on GitHub (Mar 12, 2010): Comment created by romanb: I think merge() would be the same as this: ``` foreach ($collB as $key => $element) { $collA->set($key, $element); } ``` Would it make sense to provide addAll/setAll methods? setAll would basically be the same as merge and both could easily be implemented since they can be implemented in terms of add() and set(), so change-tracking and lazy-loading is already taken care of. However, these new methods would of course only be a minor convenience.
Author
Owner

@doctrinebot commented on GitHub (Mar 13, 2010):

Comment created by shurakai:

Roman, yes, I think this might be okay. One could call in that case $collA->setAll($collB->toArray()); if i'm not mistaken? This would be really comfortable and in that case, there'd be no more need for a merge function.

@doctrinebot commented on GitHub (Mar 13, 2010): Comment created by shurakai: Roman, yes, I think this might be okay. One could call in that case $collA->setAll($collB->toArray()); if i'm not mistaken? This would be really comfortable and in that case, there'd be no more need for a merge function.
Author
Owner

@doctrinebot commented on GitHub (Mar 13, 2010):

Comment created by shurakai:

Roman, you said

{quote}this always means extending the Collection interface{quote}

in one of your statements. I'd like to point out that there are a lot of functions contained in ArrayCollection which are NOT part of the Collection Interface! (Like forAll, map, ...)

@doctrinebot commented on GitHub (Mar 13, 2010): Comment created by shurakai: Roman, you said {quote}this always means extending the Collection interface{quote} in one of your statements. I'd like to point out that there are a lot of functions contained in ArrayCollection which are NOT part of the Collection Interface! (Like forAll, map, ...)
Author
Owner

@doctrinebot commented on GitHub (Mar 14, 2010):

Comment created by romanb:

@Christian: Thats true and I think needs to be fixed or at least carefully looked at. Can you create a new jira issue for that?

Regarding setAll()/addAll(), we could make it weakly typed so that you can pass a PHP array as well as a Collection. So function setAll($collection) without a type hint, "duck-typing", basically. So $collA->setAll($collB) as well as $collA->setAll($collB->toArray()) would work the same.

@doctrinebot commented on GitHub (Mar 14, 2010): Comment created by romanb: @Christian: Thats true and I think needs to be fixed or at least carefully looked at. Can you create a new jira issue for that? Regarding setAll()/addAll(), we could make it weakly typed so that you can pass a PHP array as well as a Collection. So function setAll($collection) without a type hint, "duck-typing", basically. So $collA->setAll($collB) as well as $collA->setAll($collB->toArray()) would work the same.
Author
Owner

@doctrinebot commented on GitHub (Mar 14, 2010):

Comment created by shurakai:

I've set this state to "Won't fix" as we'll use another approach. I've opened another ticket for this.

@doctrinebot commented on GitHub (Mar 14, 2010): Comment created by shurakai: I've set this state to "Won't fix" as we'll use another approach. I've opened another ticket for this.
Author
Owner

@doctrinebot commented on GitHub (Mar 14, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Mar 14, 2010): Issue was closed with resolution "Won't Fix"
Author
Owner

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 1 attachments from Jira into https://gist.github.com/f48b82694e43415b8493

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 1 attachments from Jira into https://gist.github.com/f48b82694e43415b8493 - [10442_ArrayCollection.patch](https://gist.github.com/f48b82694e43415b8493#file-10442_ArrayCollection-patch)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#499