[Top][All Lists]

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

Re: Change in files.el

From: Eli Zaretskii
Subject: Re: Change in files.el
Date: Sat, 28 Jan 2017 18:12:48 +0200

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sat, 28 Jan 2017 18:31:29 +0300
> On 28.01.2017 17:57, Eli Zaretskii wrote:
> > These sound minor to me (and the last two are also possible without
> > the requirement, AFAIU).  By contrast, insisting on a function value
> > instead of the default nil forces me to go through at least one more
> > level of indirection when I need to understand what happens in a
> > function that references such variables, which sounds like a more
> > serious trouble from my POV.
> It's just one more level of indirection. We routinely deal with dozens 
> of them.

Each one is an additional annoyance, making maintenance harder.  Given
enough levels of indirection, it is practically impossible to
understand what the code does just by looking at the source; you need
to actually step through it in a debugger.  And that makes maintenance
a PITA, and in some cases might cause me to give up on a problem in

> This above rule should just be adhered consistently, and the
> indirection won't be a surprise every time.

There's no surprise here, only the annoying need to wade through
indirection levels.

> On the plus side, you might get a smaller function that calls the 
> -default one, because some code will be extracted.

That's only a plus when you need to write that code, not when you need
to understand or debug it.

> Finally, the default value of save-some-buffers-default-predicate can be 
> #'ignore or #'identity (it's either this, or the previous paragraph, I'm 
> not familiar with the code enough to be sure).

For predicates that need to return nil or t, the default value might
be ridiculous, if it has to be wrapped in a function.

> > I was up to my neck in this when I
> > needed to document all the various optional behaviors implemented in
> > isearch.el, and bumped into similar issues several times elsewhere.
> isearch.el and etags.el have more egregious problems, such as extensive 
> use of dynamic bindings.

Yes, and using indirection doesn't help there.

reply via email to

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