I don't understand how this will interact with byte array readers, sockets and other kinds of streams which don't have paths as such. I don't see how it could be any different from how things are right now, unless you want to generalize paths significantly. Unless this generalization (which I don't fully understand the workings of) is used, there would be two different parallel ways of using encodings, and twice as many words.
Dan On Mon, Mar 10, 2008 at 9:09 PM, Eduardo Cavazos <[EMAIL PROTECTED]> wrote: > Matthew Willis wrote: > > > I REALLY don't want working with the various formats I work with to > > become any harder than it already is. I do not want to sacrifice the > > ease of saying 'iso-2022-jp <file-reader>', 'shift-jis <file-reader>', > > and all the other adorable encodings japanese people like to use. > > In the api that I'm proposing, the examples you give above still look like > this: > > iso-2022-jp <file-reader> > > shift-jis <file-reader> > > How is that "harder" than the current api? It's in fact identical. > > Ed > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
