Re: cvs: php4 /ext/standard streamsfuncs.c

Pollita, sorry for the late reply. "Sara Golemon" <pollita@php.net> wrote: > I can easily see a user with an open outgoing stream, writting some header > or other preamble, then wanting to send the contents of an entire file: > > stream_copy_to_stream('filename.txt', $stream); > > or, equally possible and more descriptive: > > fwrite($stream, 'Content-disposition: attachment\r\nContent-encoding: > base64\r\n\r\n'); > stream_copy_to_stream('php://filter/base64.encode/resource=filename.txt', > $stream); Yes, that'd be me exactly. Note that the actual filter name is slightly longer, convert.base64-encode :) > Yes this is doable with just a few extra lines of script, but my aim here is > keeping thing simple for the end user. I had an idea very similar to yours, which didn't cover the reason Wez had added stream_copy_to_stream() instead of overloading it on copy(). For maximum simplicity, we could just get rid of fpassthru() and overload readfile() to work as it does. While that's actually the way I want things to be, there seems the matter more than backwards compatilibities. As consistency can vary how we are focusing on it, IMO it'd be the consistency to be required that the stream and the locator should have different semantics in PHP. > You don't like overloading either of these functions, that's reasonable and > laudable. However, I don't like have two functions that do each side of a > coin and leave out the middle. Is there a compromise here that can satisfy > us both? The GCD.. If fully object-oriented stream APIs were to be provided in the future, perhaps we could do things as lazily as we want to. For instance, Stream::newInstance("filename.txt", "convert.base64-encode")->drain($stream); Moriyoshi