[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal to make null string handling more emacs-y

From: Steve Yegge
Subject: Re: proposal to make null string handling more emacs-y
Date: Thu, 26 Apr 2012 16:52:31 -0700

On Thu, Apr 26, 2012 at 3:11 PM, Miles Bader <address@hidden> wrote:
Steve Yegge <address@hidden> writes:
> There's a lot of code out there that's forced to do type assertions on
> string args that could be simplified if these common functions could
> accept nils.

Maybe.  But I think such changes must be justified on a case-by-case
basis, with convincing use-cases ("in this very common situation, a nil
naturally turns up where a string was expected").

For some of them this might be justified.  For others, I see no point in
failing to deal with nil values.  There is nothing to be gained, and the
downside is that some user is sitting there unable to start Emacs because
two required packages -- packages that may be used only on demand or
not at all -- are arguing over some runtime value.  That's a big downside.
Type-checking catches a lot of bugs, even in "loose" languages like lisp
and end-user-targeted languages like elisp -- and I think the trend is
generally towards _stricter_ checking and less fuzziness, even in
scripting languages.

It's a big stretch to call the Emacs equivalent of a Java NullPointerException
"type checking".  A very big stretch.  NPEs are notorious for happening
too late to be useful.  By the time they happen, the root cause is often long
gone, produced by something not on the current call stack. 

Preventing Emacs startup because of a sudden unexpected interaction in
package dependencies does not seem like the right way for a text editor to work.


Egotist, n. A person of low taste, more interested in himself than in me.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]