On Oct 13, 2010, at 1:52 PM, Shin Fujishiro wrote: > I'm sorry but I respond to a part of your message for now. I'll post a > reply for the rest later! > > Daniel Murphy <[email protected]> wrote: >>> Input ranges can only support N-1 conversions in a sane way. They >>> can read as much items as needed from the 'front' of their underlying >>> source ranges, but can only expose a single item. >>> >>> Similarly, output ranges are restricted to 1-N conversions. >>> >>> Yeah, I know you can work around the problem by caching several items >>> inside a decorator range. It's done in your code and pretty works. :-) >>> But I think it is showing how ranges are unfit for filtering purposes. >> >> I see that caching may be undesirable in some situations, but this adapter >> (and I assume most others) can be implemented perfectly well without it. >> It's a flaw in implementation, not a limitation of ranges. > > So... how? > > To tell a truth, I've tried creating decorator ranges for character code > conversion and zlib decompression, and both required internal caching. > I think it's a limitation of the decorator design.
I'd thought so too. zlib in particular has this issue--the quality of compression is directly related to the buffer size. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
