WF>>This is frustrating (and annoying). It's a simple abstraction layer WF>>so that the zend engine can efficiently parse input from arbitrary WF>>data sources, including, but not limited to, php streams.
OK, now we are getting somewhere. The problem is that this abstraction is used in one (1) place over whole engine _and_ it abstracts it so much that leads to the situation that any extension wanting to work with file_handle beyond single operation of read cannot do so. WF>>If you told me exactly what you're trying to do, we can work together WF>>more productively. I'm trying to work with file_handle, e.g. seek it, stat it, probably something elase in the future. WF>>Instead, you've got some secret code that needs to do something WF>>magical with the stream; you won't tell me what that is, and you don't Nothing macical, just handlers implemented by php_stream, like stat and seek. And, of course, provided by stdio. WF>>If you would ask useful, practical questions, like "I need to be able WF>>to stat the stream and perform operations X, Y, Z; how can we I know how to stat the stream. The problem is that doesn't help me to stat file_handle since I don't know if it's a stream or not. And adding a copy of whole stream ops handler table and implementing all of these ops anew for FILE * just because of one zend_stream_read function seems a waste of code to me. Unless you show me the reason why zend_stream_read warrants this additional layer of abstraction. -- 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
