Daniel Ehrenberg wrote: > 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 > Hi Dan,
For byte array streams, process streams, sockets, etc the encoding would still be passed on the stack. From my point of view, the pros of Ed's approach are as follows: - If your pathname and encoding are stored in a single object, they travel as a unit on the stack, possibly making some things simpler (Ed: give some examples where you want to move a path/encoding pair around on the stack and it makes things more awkward than they need to be). - Unlike having to set the encoding after stream creation, it interacts nicely with with-file-(reader|writer). - It doesn't support from the composability problems inherent in having a global or dynamic 'encoding' variable. - Code looks almost identical, "foo" binary <file-reader> "foo" binary-file <file-reader> My concerns are: - It introduces a new concept; a pathname with an encoding. This concept exists in addition to encoding symbols. New concepts are justified when they simplify code; in this case I'm still not convinced there's really any simplification. - It might make things more confusing. Someone who doesn't know anything about the brave new world of Unicode might write "foo.jpg" <file-reader> and expect to read unmolested bytes from their file. Then they get garbage and complain that file I/O is broken. They might not even be aware that our streams support encodings, they might expect to get 8-bit "ASCII" just like in lesser languages. Having an explicit parameter there makes them explicitly state their intention. This is only a one-time thing however, once a programmer learns about encodings and the default being utf8 they're not likely to make that mistake again. Also I believe you mentioned that the probability of random binary data decoding as valid utf8 is low; so chances are they'll get an exception too. If the exception is more clear and says "UTF8 decoding failed" instead of "decode-error" like it does now, and if the :help message for that exception mentions that you can change the encoding, the chances of long-term confusion are minimal. - When defining a new type of encoding, you have to make a *-file word with effect ( string -- pathname ). Or maybe this should only exist in the case of binary-file; for other, less frequently-used encodings, you'd say "foo.txt" ebcdic encoded-file <file-reader> or whatever. But that's ugly, and no better than "foo.txt" <file-reader> ebcdic <decoder>. Personally my take on this is that having an extra symbol passed to constructors is a relatively minor issue. I'm definitely opposed to dynamically scoped encodings, but in principle I have nothing against bundling the encoding and pathname into one object. I would appreciate if the symbol-haters gave my concerns some thought and possibly either showed them to be unfounded, or came up with satisfactory solutions. In any case, I suggest we put this discussion aside for now. Mostly we're going around in circles and it's not productive. We have all stated our opinions and it doesn't look like anyone is going to budge, for now anyway. In a month or so, we'll have more experience working with these words, there will have been more discussion, and possibly someone may have put forward a truly solid proposal or two outlining suggested changes. At that point we can re-evaluate the situation and decide if we want to change the API or not. Slava ------------------------------------------------------------------------- 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
