Bug #66600
closed
- Status changed from New to Needs Feedback
Hi Philipp,
I'm not sure why you would to provide a different object then a FileReference here. And further there is this line in the code @api experimental! This class is experimental and subject to change!
We could change the code for 6.2 to something like the snippet below, but not sure if that makes sense.
/**
* @param \TYPO3\CMS\Core\Resource\FileReference $originalResource
*/
public function setOriginalResource(\TYPO3\CMS\Core\Resource\FileReference $originalResource) {
$this->originalResource = $originalResource;
if ($originalResource InstanceOf \TYPO3\CMS\Core\Resource\FileReference) {
$this->uidLocal = (int)$originalResource->getOriginalFile()->getUid();
}
}
Did you already change your custom code or is this still a issue you want to see resolved.
gr. Frans
I solved this myself by simply setting the uidLocal of my FileReference Model. As long as no one faces problems you are good i think.
I'm not sure why you would to provide a different object then a FileReference here
The param was declared as ResourceInterface before, so i thought i could pass a File object too - why not? To me this sounds just logic. The original Resource of a FileReference sounds for me to be a File object - and so i passed the File Object (it implements the ResourceInterface).
@api experimental sounds a bit funny. Either something is api or not. If something is marked api it should not change until a subversion release (6.3/7 in case of 6.2) but thats not mine to say - simply my opinnion. In public methods you should allways stick to the simply pricinple that a methods must not get more strict in its requirments (what it takes) and must not get more lazy in its output-types (what it gives). That way an api can never break.
So changing a parameter from Interface to Class = BAD. But changing a parameter from Class to Interface (if the Class implemented it before) = GOOD.
- Status changed from Needs Feedback to Closed
Also available in: Atom
PDF