Re: vc-*-root finctions

[Thien-Thi Nguyen]

() Dan Nicolaescu <address@hidden>
() Fri, 22 Feb 2008 07:42:28 -0800

   Because if forces a backend implementor to read two things
   instead of one.

Not really.  All you need to know to implement is in the
Commentary.  The rationale doesn't add any more information,
just design background.

   Well, you are effectively introducing two functions, but
   squeezing them into one with a very weird interface.  Explain
   how is that allows for less maintenance.

Look at the overall picture.  In the present system, each
backend must decide synchronicity, do scratch buffer and
subprocess maintenance, compute the result, and do a function
call.  This can be error prone (vc-svn-dir-status from vc-svn.el
1.71 leaks buffers, e.g).  In the proposed system, the backend
need only decide synchronicity and compute its result;
vc-status-refresh does the rest.

True, vc-status-refresh becomes more complex, but the overall
reduction in (redundant) complexity is a win.

   How about way too complex?

Just stick w/ the Commentary, then; that explains the interface
requirements.  Lots of things are complex in the core so that
the interfaces are simple and regular.  This is one of them.

   Can you please explain what you mean rather than hand wave?

   Given that you are replacing existing working code, it would
   be nice if you'd explain what problem you are trying to
   solve, and why the approach you took is the right way to
   solve the problem (other than applying the NIH principle).

I have tried to explain it but since i don't know where you fail
to understand things, i don't know how to explain it better.
When i fixed the vc-svn.el 1.71 bug, that was when i started to
think about eliminating the possibility of that bug.  Perhaps if
you go through the process of fixing that bug, then think along
those lines, you will arrive at similar conclusions.

   You are changing code that is simple to something that is
   strange and complex.  Enquiring minds would like to know the
   reasoning behind those changes and to make sure that the
   changes you are making are the right way to solve whatever
   problem you are trying to solve.

You ask for an explanation.  I wrote it in a comment.  You say
the comment is too complex.  But, the important thing is: it
exists.  I can now do other things while you try to understand
it.  Good luck!

   Occam's razor also applies to functions with terribly
   complicated interfaces.  So no, the above is not a good
   motivation.

What is good and what is not good?  Are bugs good?  Are systems
that breed bugs good?  Are programmers who support systems that
breed bugs good?

   And why is it better to not have a separate function?

You repeat your questions, so i repeat my answers.  See above.

thi