[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vc-*-root finctions
From: |
Thien-Thi Nguyen |
Subject: |
Re: vc-*-root finctions |
Date: |
Fri, 22 Feb 2008 18:34:33 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
() 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
- Re: vc-*-root finctions, (continued)
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/21
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/21
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/21
- Re: vc-*-root finctions, Tom Tromey, 2008/02/21
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/21
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/21
- Re: vc-*-root finctions, Tom Tromey, 2008/02/21
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/21
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/22
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/22
- Re: vc-*-root finctions,
Thien-Thi Nguyen <=
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/22
- Re: vc-*-root finctions, Mike Mattie, 2008/02/21
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/20
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/21
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/21
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/22
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/22