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

[Steve Yegge]

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.

-steve

 

-miles

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