[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]