help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Defadvice use


From: rgb
Subject: Re: Defadvice use
Date: 18 Apr 2005 17:15:41 -0700
User-agent: G2/0.2

Stefan Monnier wrote:
> > Doesn't (let (bookmark-bmenu-other-window) ...) have limited life.
>
>   (let (bookmark-bmenu-other-window) ...)
>
> only affects the bookmark-bmenu-other-window *variable*, not the
> bookmark-bmenu-other-window function.
>

If that isn't a bug waiting to happen I don't know what is.
You appear to be asserting that it's documented to work that
way but I'd counter with 2 arguments.

1.  The `feature' is only _implied_, not documented.  There is
    no mention in any Elisp manual section that covers plists
    or symbol function cells about this behavior.

2.  The `feature' invalidates much of the documented behavior of
    symbols unless you know how the symbol was created.

Look at this:

(defun test1 ()
  (let (a01)
    (put 'a01 'hold "this")
    (symbol-plist 'a01)))

(put 'a01 'hold "that") ; insure symbol already exists
(symbol-plist 'a01)
 => (hold "that")       ; value is there as expected

(test1)
 => (hold "this")

(symbol-plist 'a01)
 => (hold "this")       ; external value unexpectedly changed

(unintern "a01")        ; insure it doesn't exist
(symbol-plist 'a01)
 => nil                 ; no error.

(test1)
 => (hold "this")

(symbol-plist 'a01)    ; Given the external value should change
 => nil                ; it now unexpectedly doesn't

It's obviously impossible to easily create any function or
macro that manipulates function or property cells unless you
can guarantee none of the symbols are ever created by let.

Since it appears to be by design, I'd be terribly curious to
see any archive of discussions concerning why this is
appropriate behavior.



reply via email to

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