>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Hrvoje Niksic writes:
> Retaining a measure of backward-compatibility is important.
As much backward-compatibility as possible.
I'm sorry I haven't made that clear. I was under the impression that
this kind of thing was mostly gotten rid of by de-Ebola-ification. I
was thinking that this might be a good time to push to get rid of it
entirely, because any backward compatibility in this department is
dangerous under Mule. Apparently this is not the time.
Of course I don't speak for Ben on that.
Kyle> Thank you, thank you, thank you. I was losing faith in my
Kyle> fellow man. People support the project by writing XEmacs
Kyle> specific code and then we thank them by breaking their code
Kyle> in the name of 'modernization' or 'improvement'.
Mule, by definition, breaks the kind of code we're discussing. XEmacs
can make Mule go away, but I doubt anyone will thank us for that.
Certainly Japanese, Chinese, Indians, et al won't. And probably not
anybody, not 5 years from now, anyway.
Kyle> Leave the old APIs alone!
But we can't, without sacrificing Mule. The old APIs are simply not
well-defined in the Mule environment. Admittedly, Mule being my most
important XEmacs application, I would like those APIs, especially the
implicit ones, to go away. But I'm not adamant. For preserving
backward compatibility for well-behaved applications, I don't think
the alternatives (to removal) I've proposed are objectionable.
We do need to decide what it's going to be, and document it.
One thing I want is to discourage developers from writing new code
that will not do what they expect from it in the Mule environment. I
would prefer that the int-char, char-int, and implicit variants not be
used at all in new code. I guess that's impossible. If they must be
used, I would strongly prefer that they signal errors if they're given
things outside of the ASCII (or ISO-8859-1) domain.
--
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."