Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can UploadedFile extend SplFileInfo ? #377

Open
mattsah opened this issue Nov 8, 2019 · 11 comments

Comments

@mattsah
Copy link
Contributor

@mattsah mattsah commented Nov 8, 2019

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

This comment has been minimized.

Copy link
Member

@weierophinney weierophinney commented Nov 8, 2019

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

@mattsah

This comment has been minimized.

Copy link
Contributor Author

@mattsah mattsah commented Nov 8, 2019

@froschdesign

This comment has been minimized.

Copy link
Member

@froschdesign froschdesign commented Nov 12, 2019

@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:

@froschdesign

This comment has been minimized.

Copy link
Member

@froschdesign froschdesign commented Nov 12, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@mattsah mattsah commented Nov 13, 2019

@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

This comment has been minimized.

Copy link

@ADmad ADmad commented Nov 13, 2019

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

@weierophinney

This comment has been minimized.

Copy link
Member

@weierophinney weierophinney commented Nov 13, 2019

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

This comment has been minimized.

Copy link
Member

@weierophinney weierophinney commented Nov 13, 2019

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

@mattsah

This comment has been minimized.

Copy link
Contributor Author

@mattsah mattsah commented Nov 13, 2019

@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

This comment has been minimized.

Copy link

@ADmad ADmad commented Nov 13, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@mattsah mattsah commented Nov 13, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.