Hi,
Christoph M. Becker wrote:
On 09.01.2017 at 21:19, Andrea Faulds wrote:
Would this opaque object still allow you to use an arbitrary stream of
your choice?
Also, like with imagepng() etc., could you stream the output to uh…
PHP's default output stream? (I'm not sure what it's called. The thing
that `echo` goes to.)
It would be possible to allow either a stream URL or a stream to given,
what would fit to image(png|jpeg|…)(). However, these are "stand-alone"
functions which close the stream when they're finished, while the
animated GIF writing functions would *allow* the stream to be
manipulated by the userland developer, even though I can't see practical
reason to do so.
And, of course, we could also let the functions accept NULL to directly
write to stdout. Passing in 'php://stdout' should have the same effect.
Alright.
If it does both, I don't have much objection.
Mind you… is it really necessary to hide the stream from the user?
fopen() is not particularly hard to use, and there are (admittedly
niche) cases where you might want to handle the stream yourself.
Are there really such cases? Should we sacrifice the safety of internal
stream handling to support some (hypothetical?) use cases?
In fairness, I'm not sure. I know animated GIF streaming has been tried
before, though I doubt if it's actually used at all these days. A more
reasonable case might be embedding an animated GIF in other binary data.
But that's a hypothetical.
What is the actual “safety” gain of not using streams? That you don't
need to use fopen() yourself? (PHP will close files for you.) I'm just
not super convinced there's a need for adding this extra layer.
Thanks for your response.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
