WF>>Yes, you missed that a stream can be any stream from PHP land. If it's the PHP stream that's ok for it to be STREAM. PHP streams have own operators for foing things, so if I know STREAM type refers to PHP stream it is completely OK. What I do not understand is why you convert FP to STREAM. Only value from this conversion I can see is that zend_stream_read/zend_stream_getc now call reader instead of doing if and then calling either reader for stream or file-reading function of the engine (which, btw, is private to the engine so you even can not call or set it from outside - meaning it could be as well inlined directly in zend_stream_read/zend_stream_getc - and these seem to be the only functions that use the reader anyway).
WF>>Which code in the engine does more than read/close? My code. Since handlers using file_handle (e.g. compile_file handler) is overridable, any code can be in these handlers. And what I want is some sane rules about what can be in file_handle. Limiting file_handle to read/close only doesn't seem reasonable to me, especially that it wasn't so for a long time and only reason so far I see for it is saving two ifs - and underlying file protocols (either fd or FILE * or PHP stream) allow much more than just reading and closing. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
