> It should work with streams, no doubt about it. > I think that there should be two separate > interfaces-- at least that's what I've usually done in such situations.
An argument against that would be that both en- and decoding are simply stream transformations. It is the context (or your mind or need at that particular time) that decides whether this is a decoding or encoding transformation. In a neutral way, two transformations could be defined, and a third object (the codec) defines that transformation a is encoding while transformation b is decoding. > (or at least providing interfaces in advance to point the way, so that everything > will grow nicely together). Sure, anything we come up with should be able to adapt to common stream handling routines. What I smell is a generic interface, not belonging in codec, but in lang, for these kind of transformation. And while I think at it, I think that one will end up with something very similar to the streams classes in io (because it is justified with block handling as well as singular symbol handling). /O -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
