Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows)
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
But if you're actually going to stuff it into a TCP/IP stream via
a
process buffer, you need to use coding-system-for-process-output (or
whatever the appropriate variable is named).
OK, this is the crux of your argument, and I see what you mean.
Still, how often does coding-system-for-write differ from
coding-system-for-process-output? If such case is degenerated, then
using a coding-system-for-md5 variable might not be such a bad idea,
because it would be used only very rarely.
It seems to me that in any case where external and internal
encodings differ, Fmd5 needs to know how you plan to use its value.
In a world where the external encodings are chosen by oracle, you
need an argument to Fmd5. You can either make it explicit,
optional, and default it as Jareth has done
It's not as simple as that. Remember that we are creating, among
other things, a programming language. Before coding systems came into
the picture, Fmd5 was an exemplary of Lisp elegance:
`md5' is a built-in function
(md5 OBJECT &optional START END)
Documentation:
Return the MD5 message digest of OBJECT, a buffer or string.
Optional arguments START and END denote positions for computing the
digest of a portion of OBJECT.
This is as nice as it can get. However, with Mule, it suddenly got 10
additional lines of docstring and two more optional arguments that
have *nothing* to do with the process of md5-ing a stream of bytes,
and that are very (Mule)-implementation specific.
These uglifications are not to be taken lightly. Imagine what would
happen if we wanted to, say, add another "real" argument to Fmd5, say
GRANULARITY, or whatever? For compatibility, it would have to go
*after* the Mule arguments, and callers would have to write:
(md5 foo nil nil nil nil 10000)
The number of useless arguments is obscene. This example is, of
course, purely hypothetical (there is no such thing as MD5
granularity), and the point I'm trying to make is that interface to
user-visible Lisp functions should be well thought-out, or problems
will arise.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
- Now what did we learn from this?
- I learned what my liver looks like!