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

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Steve Yegge <steve.yegge@gmail.com> writes:

> I think we should change all the core string-manipulation functions to
> deal gracefully with nil arguments.

I think it's an intriguing idea.

Let's look at some not-quite-real bits of code.  We get a string from a
map, and then, if it exists, we want to insert it twice, capitalised.

Because `capitalize' bugs out on a nil parameter, this is how we do it
today:

(let ((foo (plist-get map 'foo)))
  (when foo
    (setq foo (capitalize foo))
    (insert foo)
    ...
    (insert foo)))

The "problem" here being the dreaded `setq'.  For reading comprehension,
its nice to not mutate variables.  If we instead allowed `capitalize' to
take a nil parameter, we'd have the more readable

(let ((foo (capitalize (plist-get map 'foo))))
  (when foo
    (insert foo)
    ...
    (insert foo)))

And we can get away with a much more functional style if we allowed
`insert' to take nil as a parameter (meaning "insert nothing"):

(insert (capitalize (plist-get map 'foo)))

instead of 

(let ((foo (plist-get map 'foo)))
  (when foo
    (insert (capitalize foo))))

I also often see code like (well, the equivalent of)

(let ((foo (capitalize (or (plist-get map 'foo) ""))))
  ...)

to avoid all the checking and `setq'-ing, but this makes the code less
clear, and you end up with nonsensical tests like `(zerop (length foo))'
later in the code if you really need to check whether you had a `foo'
there anyway.

I don't really see much of a downside to allowing (many) stringey
functions to take nil as a parameter.  And there's an upside.  So why
not?
    
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/