emacs-devel
[Top][All Lists]
Advanced

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

Re: Proper namespaces in Elisp


From: João Távora
Subject: Re: Proper namespaces in Elisp
Date: Mon, 4 May 2020 23:09:06 +0100

On Mon, May 4, 2020 at 10:51 PM Vladimir Sedach <address@hidden> wrote:
> --8<---------------cut here---------------start------------->8---
> CL-USER> (defpackage "ABC" (:use "CL") (:export "FUNC1"))
> #<PACKAGE "ABC">
> CL-USER> (defun abc:func1 (x y) (list x y))
> ABC:FUNC1
> CL-USER> (abc:func1 1 2)
> (1 2)
> CL-USER> (defpackage "XYZ" (:use "CL" "ABC"))
> #<PACKAGE "XYZ">
> CL-USER> (defun xyz::func1 (x y) (+ x y))
> WARNING: redefining ABC:FUNC1 in DEFUN
> ABC:FUNC1
> CL-USER> (abc:func1 1 2)
> 3
> --8<---------------cut here---------------end--------------->8---
>
> This causes problems when a new version of a library introduces a new
> function FUNC1, which definition gets unknowingly overridden for
> everybody by another package that uses the library. Explicitly using
> :import avoids this problem, and makes figuring out who-uses-what
> easier.

You're confused. With both :USE or :IMPORT there
is only ever one symbol named "FUNC1" in the package
named "ABC".  If someones changes the function
definition attached to it, then everybody sees it. When you
write XYZ::FUNC1 you're referring to the same symbol.

CL-USER> (defpackage "ABC" (:use "CL") (:export "FUNC1"))
#<The ABC package>
CL-USER> (defun abc:func1 (x y) (list x y))
ABC:FUNC1
CL-USER> (defpackage "XYZ" (:import-from "ABC" "FUNC1"))
#<The XYZ package>
CL-USER> (defun xyz::func1 (x y) (+ x y))
Warning: ABC:FUNC1 is defined more than once as `operator' in file NIL.
ABC:FUNC1
CL-USER> (abc:func1 1 2)
3 (2 bits, #x3, #o3, #b11)
CL-USER> (describe 'xyz::func1)
ABC:FUNC1 is a NEW SYMBOL.
  It is unbound.
  It is EXTERNAL in the ABC package and accessible in the XYZ package.
  Its function binding is #<Interpreted Function FUNC1>
    which function takes arguments (X Y)
; No values

That's the way it's supposed to work.

I don't understand how this is different from having a rogue
EL package define over a symbol in the same obarray.
I liked that your example tried to bring a real-life problem
to the table, but I can't make sense of it.

João




reply via email to

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