"Stephen J. Turnbull" wrote:

>>>>> "Ben" == Ben Wing <ben@666.com> 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");

I think you're misguided as to the correct usage of Eistrings. Eistrings are supposed to hold Mule-internal data inside them. They're definitely not supposed to hold random string stuff in them. So I'm not quite sure of what you're trying to do. Could you explain it in words? Then I'll tell you how you could do it best, using Eistrings and/or other interfaces.

If you want to copy or concatenate JIS format text, you need to mark it as JIS. For example, you could
imagine

Eistring (outline);
eicpy_ext (outline, "\033$B", Qjapanese_jis_0208);
eicat_ext (outline, "<+J,$G$7$g$&!#", Qjapanese_jis_0208);
eicat_ext (outline, "\033(B\n", Qjapanese_jis_0208);

In fact eicat_ext does not exist, so you'd have to use eicpy_ext() to create new Eistrings in those two cases, and then use eicat_ei. But the real problem here is that the data conversion that goes on inside the Eistrings is EXTREMELY SIMPLE and stateless. In fact, it just uses TO_INTERNAL_FORMAT() and TO_EXTERNAL_FORMAT() for all conversions, which assume a complete encoding block.

In your example above, you'd need to concatenate the Japanese strings together separately, using some other mechanism, and then feed the whole thing to eicat_ext(), so that it would correctly encode it into Japanese.

Or alternatively, you might be wanting to feed the bytes directly into the string? Then you can go ahead, but use Qbinary, e.g.

Eistring (outline);
eicpy_ext (outline, "\033$B", Qbinary);
eicat_ext (outline, "<+J,$G$7$g$&!#", Qbinary);
eicat_ext (outline, "\033(B\n", Qbinary);

but from the Eistring's perspective, you don't have Japanese in here; you have gobbledygook which could be decoded into Japanese. But that's not part of the design of the Eistring -- it's supposed to entirely keep
internally-formatted text in it, and provide routines to manipulate this internally-formatted text.

It seems that you're trying to rather ad-hoc-ish extend the design to do something else, and then you start complaing when there are problems! IMHO, my design is extremely well thought out.

Take a look at the example function I just posted to Hrvoje showing how this all should be used.

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@666.com> 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."

--
Ben

In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.