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
