[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange eval-after-load
From: |
Alan Mackenzie |
Subject: |
Re: Strange eval-after-load |
Date: |
Wed, 5 Jul 2006 09:57:31 +0100 |
User-agent: |
Mutt/1.5.9i |
On Wed, Jul 05, 2006 at 06:20:41AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 4 Jul 2006 22:08:05 +0100
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden
> > (eval-after-load "edebug" '(def-edebug-spec c-point t))
> > To construe this form as "modifying the behaviour of another Lisp file
> > (?edebug, presumably) in an invisible way" seems like a total perversion
> > of reality to me. I would call this e-a-l "Telling another Lisp file
> > how to handle the current one" - in essence, the module which is
> > modified by this e-a-l is cc-defs, not edebug.
> Doesn't "Telling another Lisp file how to handle the current one"
> modify the behavior of that other package in a way that isn't visible
> if you look at the code of that other package?
Whether it does or not is surely independent of whether
`def-edebug-spec' is called directly, or through eval-after-load.
Again, this change is just as visible, whichever way the function is
called. Surely?
There is nothing objectionable about using the documented functional
interface `def-edebug-spec'.
> In your example above, Edebug's behavior is modified, but one cannot
> know that by reading Edebug's code alone.
Why is this bad? Edebug provides the function `def-edebug-spec'
specifically to allow Edebug's behaviour to be modified thusly. Why is
it OK to do this in a direct call, but not OK within an eval-after-load?
Wherein lies the essential difference?
> Btw, the original text I wrote for this tip was a bit different, it
> explicitly said that eval-after-load increases a coupling between the
> two packages, which is a maintenance burden:
>
> Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
> Loading}) in libraries and packages. This feature is meant for
> personal customizations; using it in a Lisp package increases the
> coupling between it and the package mentioned in
> @code{eval-after-load}, and thus makes it harder to maintain the two
> packages independently.
How does eval-after-load change the coupling? It seems to me that all
the nasty coupling things that can happen, like accessing global
variables, implicitly sharing data structurings, etc., are completely
orthogonal to eval-after-load.
eval-after-load _decreases_ the "coupling" in an important sense - it
allows CC Mode to run without forcing Edebug to be loaded.
It is true that e-a-l makes the code more difficult to read, but then,
so do things like ,@ inside macros.
I still don't understand. I'm trying to.
--
Alan.
- Re: Strange eval-after-load, (continued)
- Re: Strange eval-after-load, David Kastrup, 2006/07/04
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/04
- Re: Strange eval-after-load, David Kastrup, 2006/07/04
- Re: Strange eval-after-load, Nick Roberts, 2006/07/04
- Re: Strange eval-after-load, Johan Bockgård, 2006/07/04
- Re: Strange eval-after-load, Thien-Thi Nguyen, 2006/07/04
- Re: Strange eval-after-load, Richard Stallman, 2006/07/04
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/04
- Re: Strange eval-after-load, Nick Roberts, 2006/07/04
- Re: Strange eval-after-load, Eli Zaretskii, 2006/07/04
- Re: Strange eval-after-load,
Alan Mackenzie <=
- Re: Strange eval-after-load, David Kastrup, 2006/07/05
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/06
- Re: Strange eval-after-load, David Kastrup, 2006/07/06
- Re: Strange eval-after-load, Richard Stallman, 2006/07/07
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/07
- Re: Strange eval-after-load, Richard Stallman, 2006/07/05
- Re: Strange eval-after-load, Richard Stallman, 2006/07/05
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/05
- Re: Strange eval-after-load, Richard Stallman, 2006/07/03
- Re: Strange eval-after-load, Richard Stallman, 2006/07/03