Hrvoje> Now I will try to answer the points you make, but I admit Hrvoje> that I no longer understand what point you are trying to Hrvoje> make. My basic point is that I think that making Emchars and Bufbytes into real objects with a linker-enforced interface would make it (eventually) easier and less buggy to work with Mule and other radical extensions of the idea that character == byte (text properties?). [...] Hrvoje> As I said above, I think it should be feasible to keep the Hrvoje> current coding conventions, and change the underlying Hrvoje> implementation. True, of course. But each time this is done it's a big, ad hoc project. It's not obvious to me what the right Mule implementation will be (I have my preferences of course). There are a number of plausible candidates (current "Mule 2.3", the FSF's "Mule 3.0", the "UTF-2000 Mule" some guys are playing with at ETL, a Unicode or UCS-4-based Mule, etc), and some people won't want Mule at all. In the end you're right that defining an interface that would make experimenting with various implementations systematic does not require dynamically loadable modules. I think a DLL implementation would enforce a very useful discipline on Mule, but self-discipline should be just as effective. -- 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 two straight lines for? "Free software rules."