I don't understand how this is better than the current system. It doesn't help us in all cases because not all streams come from a path. For example, how should byte array streams taken an encoding? Also, I don't see how this would make things better given the distribution of various encodings in the Factor code base.
Dan On Sat, Mar 8, 2008 at 10:26 PM, Eduardo Cavazos <[EMAIL PROTECTED]> wrote: > Hello, > > Slava and I discussed the unicode api. > > His main objection is selecting the encoding via a variable. > > He proposed that in the event where an encoding is not specified, that it be > utf8. The encoding can be specified as a slot value in a path object. It can > also be set as a slot value in a stream object. > > With this sytem, the stream words would never have an 'encoding' stack > parameter. > > I could live with this api. > > I haven't evaluated how it would feel in all corner cases, but it would be an > improvement over the current api. > > Slava was very clear about a certain point. Having utf8 be the encoding when > none is specified would be set in stone. Changing this "default" wouldn't be > explicitly supported (sure, someone could hack it). I'm fine with this > stance. > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
