WF>>Bitching about code breakage for something that is not in public CVS WF>>isn't going to win you any points.
Calling discussion about code "bitching" is not going to win you any points either. I do not see why code that is not in public CVS is worse than code that is or how breaking it is nicer than breaking code that is. I'm pretty sure I probably could find public code that would be broken by that too - I know a number of public code modules doing more or less the same my code does - I just don't see why it would matter even a slightest bit. WF>>This code was added specifically so that include and require will WF>>operate correctly on all php streams. Not only that, but it has been Can you please explain how converting FP to STREAM in fixup helps include/require? I don't see any benefit there. WF>>there for quite a long time now; you've had plenty of time to raise WF>>issues. That's one hell of an argument. If I didn't notice it was broken before, then it stops being broken now? Try this with bug reports: "this bug was in PHP for so long, you had a lot of time to raise issues but you didn't, so we list it as a feature". Nice, eh? So please let's discuss it to the matter. WF>>If you need to call stat from within the engine, it can be added, but WF>>you need to be aware that stat will not work in all cases, and the WF>>fact that no other place in the engine needed it at the time it was WF>>written explains why there is no stat prototype. Once again. I do not say there should be stat. I say "FP should not be converted to STREAM". That's it. Nothing more. I'm not against having STREAM type. I'm not against having FP type. I'm not agains having file_handle. Only thing I'm against is to have fixup function convert FP to STREAM and thus having STREAM mean "something you can just read and close" instead of "php_stream that you can read and close if you don't want to know about php_stream but if you want, you can do whatever php_stream can". WF>>The purpose of the stream structure is not to save ifs, it's to allow WF>>the engine to call into the php streams layer without a hard WF>>dependency on PHP, which is something you guys have been touchy about WF>>in the past. But how converting FP to stream helps that? FP is not more PHP-dependant than STREAM. Only code for which this conversion matters - as far as I see now and you didn't yet brought any example on the contrary, it you have ones please bring them forth as I really want to see them - the only such code so far is zend_stream_read. zend_stream_read is perfectly capable of handling both FP and STREAM with very minimal effort - so what exactly is the benefit of converting FP to STREAM? -- 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
