Can UploadedFile extend SplFileInfo ?

[mattsah]

Is there a particular reason that UploadedFile does not extend SplFileInfo. The only conflicting interface, which isn't even really a conflict so much is getSize() -- would there be any interest in this? I can do a PR if the interest is there.

I need this feature like yesterday and without it I'm either gonna need to look for an alternative or fork.

[weierophinney]

@mattsah Send a pull request, and we can evaluate!

[mattsah]

#378

[froschdesign]

@weierophinney
The pull request do not pay attention to the different behaviour:

Psr\Http\Message\StreamInterface defines the method getSize() with a return value of ?int and SplFileInfo::getSize with int. And additionally SplFileInfo::getSize: "An exception is thrown if the file does not exist or an error occurs."

Long story short: ?int vs. int and exception

---

Reference:

• https://www.php-fig.org/psr/psr-7/#36-psrhttpmessageuploadedfileinterface
• https://www.php.net/manual/en/splfileinfo.getsize.php

[froschdesign]

Another notice from @michalbundyra: (https://3v4l.org/DnSXf)

class A {
    public function getSize(): int {
        return 2;
    }
}
class B extends A {
    public function getSize(): ?int
    {
        return null;
    }
}

$b = new B;
var_dump($b->getSize());

This results in:

Fatal error: Declaration of B::getSize(): ?int must be compatible with A::getSize(): in

---

At the moment SplFileInfo does not define an explicit return type for getSize method but it could become a problem in the future.

[mattsah]

@froschdesign

I'm not sure I understand the first point regarding StreamInterface. That is, I don't see the relevance with respect to UploadedFile. UploadedFile appears to return ?int (from your own link), null if unknown. If a stream is passed to UploadedFile, even if it called getSize() directly on the stream, if the return typeof that is always ?int, then it falls within the appropriate return type for UplaodedFile.

Regarding SplFileInfo. Per PSR-7 spec, the getSize() is intended to return the size as actually transferred:

* Implementations SHOULD return the value stored in the "size" key of
* the file in the $_FILES array if available, as PHP calculates this based
* on the actual size transmitted.

Assuming this is accurate, the size transferred, could always be 0 or > 0 -- which means, while UploadedFile may not throw an exception the same as SplFileInfo, it will always report the actual size of an uploaded file... which just happens to be 0 in the event of failure or if not reported by SAPI.

I think the case I'm not understanding is where UploadedFile::getSize() would return NULL -- this would certainly conflict with SplFileInfo. But under what condition does this occur?

In either case, neither UploadedFile or SplFileInfo actually typehint return. If PHP is willing to break backwards compatibility, I'd think all bets are off for libraries and you're in a position to address BC breaks regardless. If PSR-7 changes the actual programmatic interface, presumably that would require a potentially significant update anyway, including requiring newer versions of PHP.

[ADmad]

I have raised other concerns on the related pull request #378 (comment).

[weierophinney]

In either case, neither UploadedFile or SplFileInfo actually typehint return. If PHP is willing to break backwards compatibility, I'd think all bets are off for libraries and you're in a position to address BC breaks regardless. If PSR-7 changes the actual programmatic interface, presumably that would require a potentially significant update anyway, including requiring newer versions of PHP.

FIG is actually currently voting on by-laws that will allow adding typehints that conform with the already declared signatures (this would be accomplished via a two-tiered approach to allow libraries to create first a forwards-compatible version, and then break BC to adopt all typehints). As such, libraries that provide implementations MUST follow the specified contract.

[weierophinney]

I've submitted a patch to revert the change in #379

[mattsah]

@weierophinney

Sure, but adding a typehint of ?int to getSize() will not actually cause an issue when extending SplFileInfo as it predates strict interfaces, that is SplFileInfo says it returns int or throws exception, but it does not have a typehint that would require compatibility in the first place and is implicitly a mixed result in terms of actual code.

With respect to other issues raised. SplFileInfo does not go "kaboom" -- it does exactly what it does in any case where the file does not exist as can easily be demonstrated by the following:

matt@havana:~$ php -r "(new SplFileInfo('/tmp/test'))->getMTime();"
PHP Fatal error:  Uncaught RuntimeException: SplFileInfo::getMTime(): stat failed for /tmp/test in Command line code:1
Stack trace:
#0 Command line code(1): SplFileInfo->getMTime()
#1 {main}
  thrown in Command line code on line 1

SplFileInfo is not intended to only function on existing files. You can add any path you like to it in order to try and grok information. If someone is trying to get the m time of a file they are going to have to make sure the file exists first anyhow using SplFileInfo::isFile() or something similar.

It seems unfortunate that this was reverted for SplFileInfo responding as it should.

[ADmad]

@mattsah SplFileInfo is meant for file paths (whether they exist or not). It's not meant to be used for stream paths. Treating stream paths as non existent file paths is simply not right (especially when the stream path is valid).

[mattsah]

@ADmad I guess people better stop using rename() for streams then, since according to the documentation "rename — Renames a file or directory" and a stream is neither of those.

PHP has gone through a long process of progressively adding stream support and stream wrappers to places where previously only normal files could be used. Pointing out that PHP is inconsistent and/or doesn't provide proper/meaningful support for streams in all such places doesn't seem like a very good argument against this feature.

A stream is a non-existent file, because it's not a file... it's a stream.

[weierophinney]

This repository has been closed and moved to laminas/laminas-diactoros; a new issue has been opened at laminas/laminas-diactoros#3.