From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: vc-*-root finctions Date: Fri, 22 Feb 2008 18:34:33 +0100 Message-ID: <87skzk3nfa.fsf@ambire.localdomain> References: <87skzn3mq9.fsf@ambire.localdomain> <87mypvxzd2.fsf@ambire.localdomain> <200802201850.m1KIofIk000198@sallyv1.ics.uci.edu> <87tzk2xr2q.fsf@ambire.localdomain> <200802211835.m1LIZcZ5005055@sallyv1.ics.uci.edu> <87ablt3vfx.fsf@ambire.localdomain> <200802221542.m1MFgSre027158@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203701837 12763 80.91.229.12 (22 Feb 2008 17:37:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2008 17:37:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 22 18:37:41 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JSbpi-0002TD-L0 for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 18:37:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSbpD-0006YX-BM for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 12:36:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JSbp9-0006Va-4K for emacs-devel@gnu.org; Fri, 22 Feb 2008 12:36:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JSbp8-0006V0-FW for emacs-devel@gnu.org; Fri, 22 Feb 2008 12:36:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSbp8-0006Ux-AZ for emacs-devel@gnu.org; Fri, 22 Feb 2008 12:36:38 -0500 Original-Received: from [151.61.143.248] (helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JSbp7-0007hj-Pc for emacs-devel@gnu.org; Fri, 22 Feb 2008 12:36:38 -0500 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1JSbn7-0002me-K1; Fri, 22 Feb 2008 18:34:33 +0100 In-Reply-To: <200802221542.m1MFgSre027158@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Fri, 22 Feb 2008 07:42:28 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:89990 Archived-At: () Dan Nicolaescu () 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