[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: Multiple major modes
From: |
Eric M. Ludlam |
Subject: |
Re[2]: Multiple major modes |
Date: |
Wed, 4 Jul 2007 21:44:24 -0400 |
>>> Richard Stallman <address@hidden> 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: address@hidden, address@hidden
Home: http://www.ludlam.net Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
- Re: Multiple major modes, (continued)
- Re: Multiple major modes, Richard Stallman, 2007/07/08
- Re: Multiple major modes, Stephen J. Turnbull, 2007/07/07
- Re: Multiple major modes, Stefan Monnier, 2007/07/06
- RE: Multiple major modes, Drew Adams, 2007/07/06
- Re: Multiple major modes, Richard Stallman, 2007/07/07
- Re: Multiple major modes, Stephen J. Turnbull, 2007/07/07
- Re: Multiple major modes, Richard Stallman, 2007/07/08
- Re: Multiple major modes, Stephen J. Turnbull, 2007/07/09
- Re: Multiple major modes, Richard Stallman, 2007/07/09
- Re: Multiple major modes, Johan Bockgård, 2007/07/06
Re[2]: Multiple major modes,
Eric M. Ludlam <=
Re: Multiple major modes, Richard Stallman, 2007/07/01