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. Perhaps I'm missing something? Please tell us if you know a way to implement M:N decorators without caching! Shin _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
