emacs-devel
[Top][All Lists]
Advanced

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

suggestion on adding arguments to existing functions


From: Drew Adams
Subject: suggestion on adding arguments to existing functions
Date: Fri, 25 Nov 2005 14:16:43 -0800

I don't want to start a war on this, but I'd like to make a suggestion wrt
the general procedure of adding arguments to existing functions. It's
possible that I'm missing something - if so, that might be good to discuss,
but otherwise, please just take this suggestion into consideration.

Here's an example of a function signature in Emacs 20 and in Emacs 21:

(dabbrev--substitute-expansion old abbrev expansion)

(dabbrev--substitute-expansion old abbrev expansion record-case-pattern)

The library that uses this function, dabbrev.el, only calls it in two
places, one of which uses the value nil (which is equivalent to using the
old form).

My suggestion is to use `&optional' in a case like this, other things being
equal (that is, if there is no good reason not to). Why? Because otherwise
it unnecessarily breaks libraries that use the old form and (more
importantly, to me) libraries that try to work with multiple versions of
Emacs. It makes those libraries use ugly constructs such as this (or a macro
that does the same thing):

(if (< emacs-major-version 21)
    (dabbrev--substitute-expansion nil abbrev init)
  (dabbrev--substitute-expansion nil abbrev init nil))

Not only is that unnecessarily ugly, but, in the general case, it means
needing to examine various Emacs versions to find out exactly when the arity
was changed (to get the version test right).

[Now, if there were a function that we could use to test the arity, that
would also be welcome here (a version test is not the first choice, if there
is an alternative). In Emacs 21 and 22 there is `sub-arity', but that only
works for built-in functions, IIUC.]

Why "unnecessarily"? Because if the function were extended with `&optional'
then there would be nothing to do. (Even the changes to Emacs itself would
be easier - in this case, one of the two calls would not need to change, and
that's the average case for a binary value: 50%.)

This example involves a change made between Emacs 20 and 21, but the
suggestion is general and concerns only future changes - it's just something
you might keep in mind.

I understand that backward compatibility is not a priority for Emacs
developers. Nevertheless, if there is no good reason not to take code
evolution into account in a given case (e.g. if there is no added cost in
performance, clarity, development, maintenance,...), then why not do so?

Thanks for thinking it over.





reply via email to

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