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

[Steve Yegge <steve.yegge@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Thu, Apr 26, 2012 at 3:11 PM, Miles Bader <miles@gnu.org> wrote:

> Steve Yegge <steve.yegge@gmail.com> 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.
>

[-- Attachment #2: Type: text/html, Size: 2562 bytes --]