[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c
On Tue, 07 Jan 2003, Moriyoshi Koizumi wrote: moriyoshi Mon Jan 6 19:03:26 2003 EDT Modified files: /php4/ext/standardfilters.c Log: Implemented string.base64 stream filter @- Implemented string.base64 stream filter. (Moriyoshi) Couldn't you have used parts of ext/standard/base64.c here instead of duplicating code? -Andrei http://www.gravitonic.com/ The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian proverb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c
Hi, On Tue, Jan 07, 2003 at 12:12:15PM -0800, Sara Golemon wrote: Speaking of filter string.base64 I have an issue with its parity. string.base64 will encode on write and decode on read... What if the user wants the other way round? Is the expected behavior even obvious from the name alone? Should there be two separate filters? string.base64-encode string.base64-decode with each doing the same opperation on either read or write? Agreed. I hit the same problem you mentioned while implementing iconv encoding conversion filter. I should have made the filters capable of working in the opposite way. But would it rather be preferred to switch the filter function by parameters given to the factory, than to have two similar filters? Then the problem is there's no unified way to handle those parameters. Actually it will do for me to make my own handler, but I see it will definitely end up in great inconsistency. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c
With the current model, the concept is that you can use either the filter name or filter parameters to distinguish the ultimate behaviour. Yes this is a possible headache. I am thinking that two separate chains of filters (one for reading and one for writing) might make this situation a little easier; this way you could have a filtered read stream but leave writing unfiltered etc. --Wez. On Wed, 8 Jan 2003, Moriyoshi Koizumi wrote: Hi, On Tue, Jan 07, 2003 at 12:12:15PM -0800, Sara Golemon wrote: Speaking of filter string.base64 I have an issue with its parity. string.base64 will encode on write and decode on read... What if the user wants the other way round? Is the expected behavior even obvious from the name alone? Should there be two separate filters? string.base64-encode string.base64-decode with each doing the same opperation on either read or write? Agreed. I hit the same problem you mentioned while implementing iconv encoding conversion filter. I should have made the filters capable of working in the opposite way. But would it rather be preferred to switch the filter function by parameters given to the factory, than to have two similar filters? Then the problem is there's no unified way to handle those parameters. Actually it will do for me to make my own handler, but I see it will definitely end up in great inconsistency. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c
oooh yes, good point: stream_filter_append($fp, string.base64, encode); and stream_filter_append($fp, string.base64, decode); probably with encode being the default behavior. That make implementation very simple and in fact the toupper/tolower calls should be similarly combined into a single filter class (string.case ?). What is the preferred way of passing multiple parameters? I know each filter could handle it differently, but consistency is also a very nice thing. Coma separated perhaps? Changing the behavior of stream_append to use an array instead of a string? (might be going a bit far, but would give maximum flexibility) With the current model, the concept is that you can use either the filter name or filter parameters to distinguish the ultimate behaviour. Yes this is a possible headache. I am thinking that two separate chains of filters (one for reading and one for writing) might make this situation a little easier; this way you could have a filtered read stream but leave writing unfiltered etc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c
Couldn't you have used parts of ext/standard/base64.c here instead of duplicating code? At first I thought of using php_base64_encode() and php_base64_decode() rather than reimplementing them. But because those functions are designed to be used in string semantics while streams require a different facility due to its statefulness, I couldn't use the existing implementation. Speaking of filter string.base64 I have an issue with its parity. string.base64 will encode on write and decode on read... What if the user wants the other way round? Is the expected behavior even obvious from the name alone? Should there be two separate filters? string.base64-encode string.base64-decode with each doing the same opperation on either read or write? I'm personally conflicted on which way it should be, but I wanted to raise the questions so that we could dialouge. The questions apply to string.quoted-printable for that matter. (( string.rot13 is fully symmetric so its the same no matter how you slice it, and string.to(upp|low)er are both fully asymmetric so only one implementation makes any sense. )) -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
