Re: proposed Eistring interface

>>>>> "Ben" == Ben Wing <ben(a)666.com&gt; writes: Ben> I'm surprised you're so worked up over a silly convenience Ben> function! If you say it's just a convenience function, OK with me. I have nothing against convenience functions, in particular this one. I wrote that already. But I don't understand your restriction. Can't I have some of that convenience, too, then? Eg, I see absolutely nothing wrong with the following use of that convenient interface (forgive me if the idiom is incorrect, and I know the use of the literal JIS in the 2d invocation of eicpy_c is entirely bogus): Eistring (outline); eicpy_c (outline, "\033$B"); eicpy_c (outline, "<+J,$G$7$g$&!#"); /* this should come from an lstream or something */ eicpy_c (outline, "\033(B\n");

That would be one way to reimplement encode-coding-region for ISO-2022-JP. According to your proposal that would be verboten, as would use of literals for SS3 (a C1 character used in EUC-JP for JIS X 0212). Isn't prohibiting those pretty silly? What do I use instead? There is no interface for escape sequences, unless it's eicpy_ext (outline, "\033$B", Qascii); On the other hand, I don't think that that interface (the ei*_ext* APIs) should be exposed to anybody except people involved in implementing "decoding lstreams". (I note that you made exactly that restriction on eicpy_lstream.) Summary: as I see it you want to ban usages that are perfectly safe in the hands of the target audience of hardened Mule developers, while allowing (or at least advertising) usages that cannot be safe without substantial extra, tricky code around them. That tricky code should be encapsulated, but I don't think it belongs inside the Eistring stuff. That makes me wonder what you are thinking about. And that's what the fuss is about -- I'm just asking you the same kind of question you've been asking -Bill P. Have you really thought this through, or are you just reorganizing a basically untenable interface? I guess having thought about it this far, I don't think it's untenable even in this aspect. I do want to see (1) an interface for literal control sequences (either an error- checking one that will be inconvenient, or elimination of the restriction of eicpy_c to ASCII) (2) severe restrictions on the use of the ei*_ext* APIs, preferably to the implementation of decoding lstreams. "Better to be correct than fast." -- Ben Wing in <38FD6F11.654F3132(a)666.com&gt; Or excessively complete, at least in the semi-public interface. I think that would relieve my discomfort with the proposal as it stands.[1] Other than that, it seems quite complete, it's very regular, and I think having a standard set of easily identifiable idioms that hide the internal representation most of the time will eventually make reading Mule code a lot easier than it is now. Footnotes: [1] And if in practice (2) turns out to be too restrictive, I would be amenable to loosening restrictions as necessary -- upon discussion. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."