Re: zend_stream_fixup
| From: | Stanislav Malyshev | Date: | Sun, 13 Mar 2005 16:30:04 +0000 |
| Subject: | Re: zend_stream_fixup | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-15418@lists.php.net to get a copy of this message | ||
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
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115