Re: [External] : Re: master a7c65fc666: Allow nil value for filter-buffer-substring-function

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> I don't think that point was given.  My point was
> that an argument that nil should be disallowed for
> variables whose names end in `-function' is wrong
> (misguided).  It may be reasonable for variable
> `filter-buffer-substring-function', and for some
> other so-named variables.  But as a general rule
> it's misguided, IMO.

Is that written somewhere, or did only say someone that we have that
rule, or people should, if possible, follow that rule?

In (info "(elisp) Coding Conventions") I read

   • If the purpose of a variable is to store a single function, give it
     a name that ends in ‘-function’.  If the purpose of a variable is
     to store a list of functions (i.e., the variable is a hook), please
     follow the naming conventions for hooks.  *Note Hooks::.

It doesn't tell anything about the other direction (name -> restriction
to certain values).

In the Emacs Elisp sources I find over hundred `defvar's of symbols
named "*-function" that default to nil.  Doesn't seem to be a very
strict thing.

Maybe a good rule would be "[now that we have nadvice] please think about
whether someone or somecode might want to advice that binding before
allowing arbitrary values for *-function named variables".  Maybe it
would a good idea to spell that hint out in the manual if it isn't yet
(didn't check).

> > I don't think testing the value directly for equivalence
> > to some given value is not an important use case:
>
> You don't think it's _not_ an important use case?
> Or was that a typo?  I'm guessing the latter,
> based on the rest of what you say.

Yes, thanks for the correction.

> In any case, it may not be important to you, and
> it may not be general enough for you or for
> everything.  But it can be an important use case
> for some code - for some `-function' vars, IMO.
>
> I see no reason that a convention for naming vars
> `-function' should be limited to variables whose
> value can _only_ be a function.

I agree it should not be a strict must.  More a guideline to follow when
no reasons speak against it.  There are cases where other value types
and a *-function name fit.

> (_Does_ the doc call it out for this var?)

Yes.  Implicitly, but clearly.

> Speaking of which - I think it's a mistake BTW for
> function `advice--p' to be "internal".  It's fine
> that its implementation might change.  But it's a
> fine function for user code to use.  There's no real
> alternative, other than directly using the code that
> implements it.  (Likewise for `advice--car' etc.)

Dunno if `advice--p' has non-internal use cases.  We have some related
"public" functions in nadvice that might suffice: `advice-mapc' and
`advice-member-p'.

Michael.