Re: files.el: Patch to make project-settings optional/customizable

[Dan Nicolaescu <dann@ics.uci.edu>]

Juri Linkov <juri@jurta.org> writes:

  > > So there are 2 uses .dir-locals.el 3 lines apart in the same 24 lines function.
  > > The defconst adds 4 lines.  It's hard to keep a straight face and claim
  > > that the defconst is a good idea.
  > > (and the 2 uses could be reduced to a single one if we make
  > > locate-dominating-file return an expanded file name -- which seems to be
  > > a good idea anyway).
  > >
  > > It's kind of painful that this discussion is still going on, it should
  > > have never occurred in the first place...
  > 
  > I can't believe we have this kind of discussion :(
  > 
  > All packages with similar functionality have defcustom for the file name.
  > dir-locals.el was created in 2005 and dirvars.el in 2002.
  > For several years they provided customization without problems.

This has been discussed to death, and someone said it very well upthread:
"it's broken by design".

  > Our discussion reached the need to make this file name constant.

How was it not a constant before the change?

  > I'm ok with this conclusion.  So I created defconst because it
  > explicitly says that the file name should not be modified by the user,

What does that accomplish that the previous code or adding a comment to
the code did not?  
Why is this better encapsulation?

  > unlike if it was hidden in the function dir-locals-find-file where users
  > will be the temptation to redefine the whole function without understanding
  > that the file name have to be constant.

Why is the danger of redefining a function greater than simply using setq?