[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: |
Miles Bader |
Subject: |
Re: proposal to make null string handling more emacs-y |
Date: |
Fri, 27 Apr 2012 09:29:32 +0900 |
Steve Yegge <address@hidden> writes:
>> 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.
Signalling an error _is_ "dealing with nil values" (and very often the
correct way).
Anyway, I think the onus is on you to show that relaxing
error-checking is justified.
> There is nothing to be gained
Clearly there is: less buggy code.
> 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.
WTF do you keep going on about Emacs startup?
If Emacs is dealing poorly with errors during startup -- of which
nil-when-a-string-was-expected is just one not particularly noteworthy
example -- then Emacs' handling of errors during startup needs to be
made robust.
Just papering over the problem by ignoring bugs simply means Emacs
will be more buggy. That hurts users.
>> 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.
Use whatever terminology you like. It doesn't change the issues.
-miles
--
Any man who is a triangle, has thee right, when in Cartesian Space,
to have angles, which when summed, come to know more, nor no less,
than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR]
- Re: proposal to make null string handling more emacs-y, (continued)
- Re: proposal to make null string handling more emacs-y, Eli Zaretskii, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Stefan Monnier, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Eli Zaretskii, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Stefan Monnier, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Miles Bader, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Andreas Schwab, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Juanma Barranquero, 2012/04/25
- Re: proposal to make null string handling more emacs-y, Steve Yegge, 2012/04/26
- Re: proposal to make null string handling more emacs-y, Miles Bader, 2012/04/26
- Re: proposal to make null string handling more emacs-y, Steve Yegge, 2012/04/26
- Re: proposal to make null string handling more emacs-y,
Miles Bader <=
- Re: proposal to make null string handling more emacs-y, Jeremiah Dodds, 2012/04/26
- Re: proposal to make null string handling more emacs-y, Miles Bader, 2012/04/26
- Re: proposal to make null string handling more emacs-y, Jeremiah Dodds, 2012/04/27
- Re: proposal to make null string handling more emacs-y, Miles Bader, 2012/04/27
- Re: proposal to make null string handling more emacs-y, Thien-Thi Nguyen, 2012/04/27
- Re: proposal to make null string handling more emacs-y, Nix, 2012/04/27
- Better startup error handling (was: proposal to make null string handling more emacs-y), Stefan Monnier, 2012/04/27
- Re: Better startup error handling, Nix, 2012/04/28
- Re: Better startup error handling, Stefan Monnier, 2012/04/28
- Re: Better startup error handling, David Engster, 2012/04/28