Open WyrdNexus opened 7 years ago
As a simple suggestion, perhaps Collection should implement Selectable, and the whole issue disappears.
no common Class or Interface reflects their shared methods
This is true unfortunately.
As a simple suggestion, perhaps Collection should implement Selectable, and the whole issue disappears.
Impossible due BC, would be a BC break -- only possible in next major of doctrine/collections. Also possibly not a wise idea -- consider this architecture more in general / different scenarios outside ORM. it doesn't always make sense to have selectable collection.
Regarding ORM, this could be only solved in 3.x somehow, if you have any proposals, ideally without breaking doctrine/collections, you're welcome to send PR for that or discuss here. 👍
Notation Key:
As this would neither remove nor alter any methods, classes, or interface implementations, I fail to see how this would cause a BC break. The only real limitation here, is that it would require two paired PRs against the Collections repository and the ORM Repository.
I fail to see how this would cause a BC break.
In your proposal, Collection suddenly extends Selectable, thus requires implementation for matching()
. This method previously did not exist in the Collection interface so any code implementing (just) Collection is now suddenly required to also implement new matching()
method, which is a BC break.
The Selectable
interface was added a long time after Collection
was finalized. A change to this interface would have been a BC break.
The solution would be that "collections" introduces a third interface SelectableCollection
that extends from Collection and Selectable and to change both ArrayCollection
and PersistentCollection
to use that.
This must be done in two steps:
1.) Add SelectableCollection
to "doctrine/collections", have ArrayCollection
extend it and release a new version (minor bump enough, because its not a BC break).
2.) Bump dependency of "doctrine/orm" to new "doctrine/collections" version and change PersistentCollection
.
@WyrdNexus did you figure out a workaround for this issue? (without dropping the returntype typehint)
The only real limitation here, is that it would require two paired PRs against the Collections repository and the ORM Repository.
Please don't forget MongoDB ODM, where PersistentCollection
doesn't implement Selectable
.
@alcaeus if a new interface is created, there is no issue for the ODM, as Collection would still not require implementing Selectable.
@stof I was replying to @WyrdNexus who suggested that the Collection
interface extends Selectable
, with PersistentCollection
implementing Collection
: this would indeed also affect ODM. A new, separate interface (SelectableCollection extends Selectable, Collection
) would not directly impact ODM.
How do you thing about toArray() Method?
I had this issue on my documents and corrected the bug with that
/**
* @return array
*/
public function getMetas(): array
{
return $this->metas->toArray();
}
/**
* @param array $meta
*
* @return self
*/
public function setMetas(array $meta): self
{
$this->metas = $meta;
return $this;
}
/**
* @param Meta $meta
*
* @return self
*/
public function addMeta(Meta $meta): self
{
$this->metas[] = $meta;
return $this;
}
Doctrine will parse the array before insert and The document could be manipulate without The Collection type hinting
Any news/plans on this? This is really frustrating when you are working with PHPStan.
If you use phpstan/phpstan-doctrine
it contains an extension to pretend that the Collection
interface contains a matching
method. As long as you're not using MongoDB ODM, you might be safe unless you've created custom collection implementations.
The other alternative is to annotate return types using a union type (Collection&Selectable
) - PHPStan will understand this, but other tools (notably PhpStorm) may not.
While Doctrine will provide either an ArrayCollection, or a PersistentCollection, depending on the state of the Entity, no common Class or Interface reflects their shared methods.
More specifically, when defining an entity's collection getter, the return type cannot be specified. Options include:
This missing common agreement complicates all code implementing these objects, which otherwise could be clean and simple.
For the sake of clarity, consider the PHP7 return type declaration on the getter for such a method. Both of the following week result in errors: pubic method getOneToMany(): ArrayCollection pubic method getOneToMany(): PersistentCollection The best alternative is: pubic method getOneToMany(): Collection ... leaving out the method: matching.