"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
[...]
Stephen, I'm not sure what we are discussing here anymore. Let me
just stress two few points I consider important:
* I hope I have now explained why it is technically very hard or
impossible to *dynamically* load/unload an overwhelming extension
such as Mule. This is what you apparently wanted from the new
module stuff, and this is what I originally answered you about.
* Mule coding conventions may be complex, but they are not bad, and
not too hard to follow, once you get used to them (quite unlike
GCPRO, I'd say.)
And they *are* an abstraction -- at this time, with a flip of a
lever (#define/undef MULE) you can build two totally different
XEmacsen off the same general code. I can easily imagine there
existing a third one, based on Unicode or whatnot.
Now I will try to answer the points you make, but I admit that I no
longer understand what point you are trying to make.
> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>
> >> Making people who have little direct interest in MULE conform
> >> to complex coding conventions that they don't understand is
> >> bad. If functions that must be MULE-aware could be localized
> >> to a smaller set of modules, it would be a good thing.
>
> Hrvoje> You can't localize general concepts like "characters are
> Hrvoje> not 1 byte".
>
> Of course you can, by making an opaque character object type and
> manipulating instances only through messages.
I believe that's what we have now (more or less), and it does involve
a certain discipline. What is Emchar if not "opaque character object
type"?
> We may not like the amount of work involved or the efficiency loss.
> The fact that 66 of the 201 .c files in my current xemacs-21/src
> directory contain a reference to Emchar or Bufbyte suggests it'd be
> horrendous. :-(
What exactly do you find wrong with Emchar and Bufbyte? Why do you
think a different implementation should get rid of those interfaces?
> Hrvoje> If third-party contributors don't understand Mule coding
> Hrvoje> conventions, too bad for them. Besides, the conventions
> Hrvoje> are not all that complex, once you get to know them --
> Hrvoje> which goes for the rest of the XEmacs C sources.
>
> <DIV ATTITUDE="tongue-in-cheek">
> You are of course referring to the GCPRO convention?
> </DIV>
If you want it that way, yes, although you've intentionally chosen a
very controversial point. To get a different point of view, try
asking Michael Sperber what he thinks about "helpful" allocators that
obviate the need for GCPRO.
> I don't contest your points, pragmatically. But even now we still
> have problems with integer vs. character comparisons cropping up
> every once in a while.
And your point is...?
> Also, eventually we are going to have to modernize Mule; the current
> implementation is just too constraining with the Japanese talking
> about creating a completely new character set standard which will
> have to coexist with the old one, only about 20% of the Chinese
> standards implemented as yet, and Unicode not implemented at all.
As I said above, I think it should be feasible to keep the current
coding conventions, and change the underlying implementation.
