RE: [External] : Re: Shrinking the C core

[Drew Adams <drew.adams@oracle.com>]

(Again, moving to emacs-tangents@gnu.org.)

> Agreed, it is better with keyword arguments than 
> a long list of nils because of optional arguments.
> 
> But it is better yet to not have the functions take so many
> arguments in the first place, but to split them up and have
> the function name be more specific what is going to happen.

Not necessarily.  It depends - on context, how
often each combination is used, and even user
preferences.

With 10 different functions, instead of one,
to represent a "family" of functions, users
can wonder "Which should I use?".  The problem
introduced then is finding good function names
and specifying, in the doc of each (or in some
"family" doc) just what the differences are,
and how they can (or can't) be used together.

IOW, it can make sense to use a "family" name
and keywords, with a single explanation of the
keywords, together.  A single explanation lets
you address what combinations make sense etc.

Happily, if keywords are at least available
(possible) in the language, you have a choice
of which approach to use.  Nothing _requires_
you to define a function with keyword args,
instead of defining separate functions (up to
N-factorial of them!).