From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re[2]: Multiple major modes Date: Wed, 4 Jul 2007 21:44:24 -0400 Message-ID: <200707050144.l651iOeu023173@projectile.siege-engine.com> References: <466E7A93.3050705@gmail.com> <466E81AA.3030202@gnu.org> <466E9822.2050508@gmail.com> <466EAB9D.9020408@gnu.org> <466EEA71.2070700@gmail.com> <200706122014.l5CKEKV1021902@projectile.siege-engine.com> <200706190209.l5J29Csr010302@projectile.siege-engine.com> <200706251404.l5PE4dgc011720@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1183599883 17119 80.91.229.12 (5 Jul 2007 01:44:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2007 01:44:43 +0000 (UTC) Cc: jasonr@gnu.org, lennart.borgman@gmail.com, sdl.web@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 03:44:40 2007 connect(): Connection refused 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 1I6GOc-0006Fb-FB for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 03:44:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6GOb-00075Y-TY for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 21:44:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6GOY-00075T-I5 for emacs-devel@gnu.org; Wed, 04 Jul 2007 21:44:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6GOW-00075H-W5 for emacs-devel@gnu.org; Wed, 04 Jul 2007 21:44:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6GOW-00075E-T3 for emacs-devel@gnu.org; Wed, 04 Jul 2007 21:44:32 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10] helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I6GOR-0006un-4J; Wed, 04 Jul 2007 21:44:27 -0400 Original-Received: from projectile.siege-engine.com (localhost.localdomain [127.0.0.1]) by projectile.siege-engine.com (8.12.8/8.12.8) with ESMTP id l651iPYE023177; Wed, 4 Jul 2007 21:44:25 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.12.8/8.12.8/Submit) id l651iOeu023173; Wed, 4 Jul 2007 21:44:24 -0400 In-reply-to: (message from Richard Stallman on Sun, 01 Jul 2007 16:40:13 -0400) X-detected-kernel: Linux 2.4-2.6 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:74327 Archived-At: >>> Richard Stallman seems to think that: > The function overload mechanism is also a feature I use in semantic. > Most features that work in multiple major modes today provide a > variable where you can put a symbol that is a function that would then > provide some mode-specific functionality. > > My semantic tool has hundreds of these functions, so I abstracted the > concept up so that the implementations could be declarative, instead > of programmatic. > >I really don't like the idea of function overloads. This mechanism >shares the drawbacks of advice: that a function doesn't do what its >definition says. > > It also makes it easy to make most functions > overridable, which helps avoid forcing users to use advice when > customizing my tool. > >It is easy to replace advising with another similar mechanism, >but it doesn't solve the problem. > >It seems to me that there is no need for this. Calling a variable >with funcall should do the same job. That way, the call _shows_ >that the function isn't fixed. The use syntax of an overloadable function is similar to programs that call `indent-for-tab-command', or `indent-according-to-mode', but there is no restriction forcing `according-to-mode' as part of the function name. The difference between writing an `indent-according-to-mode' function and an overload function is that you don't have to write the body of the function or, in the specific case of `indent-according-to-mode', you could write a body that wraps up an :overload token similar to the way `indent-according-to-mode' wraps the `funcall'. Anyway, I think these overload functions are more like methods which dispatch on major mode instead of advice. You can advise any function, but you can only overload something created with `define-overload', so it is known via syntactic sugar instead of a funcall call. When it comes right down to it though, this is not needed for multiple major modes where one of the concerns is buffer-local vs mode-local variables, and I don't want to imply that I think it is needed. It is only a feature which I feel has enhanced the maintainability of my code, and has helped others understand and discover how to extend my tools for different modes. Eric -- Eric Ludlam: zappo@gnu.org, eric@siege-engine.com Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org