4 ms·

An introduction to Names: practical namespaces for Emacs-Lisp

14 points by malabarba 12y ago

e40 12y ago
So, because RMS doesn't like CL packages we get something that is clearly inferior to CL packages and implemented in a very hacky way (a macro you wrap around all the forms in a given .el file). Sometimes, when you avoid solutions for political reasons, you end up with something worse for political reasons. <sigh> Sometimes the world is frustrating.
- agumonkey 12y ago
  Don't be too stiff, having a working hack is a good thing, it helps discussions with concrete examples and usages. Hopefully if things start to move, 'cleaner' solutions will be picked.
- malabarba 12y ago
  I understand your feelings, but I'm not avoiding anything. :-) I wrote a compliant solution instead of spending my time begging for something else.
teddyh 12y ago
I think I’d prefer it if the symbols to be prefixed with a namespace required a :: instead of having to prefix every external call with ::. I.e. I would prefer (require 'externalpackage) (define-namespace thispackage- (defvar ::foo "yow") ; foo is explicitly local, and ; since it is short, an extra ; "::" does not make much ; difference (externalpackage-frobnicate ::foo) ; frobnicate is external ) to this, which is how the package works currently: (require 'externalpackage) (define-namespace thispackage- (defvar foo "yow") ; Some things like defvar ; magically don’t need :: (::externalpackage-frobnicate foo) ; Ugly, and I need to do this ; for *every* non-local symbol, ; making them even longer! )
- malabarba 12y ago
  No, you don't need to do that for every non non local symbol. You only need to do that for external symbols which are shadowed by a local symbol (which has never happened to me so far).

14 points by malabarba 12y ago

e40 12y ago

So, because RMS doesn't like CL packages we get something that is clearly inferior to CL packages and implemented in a very hacky way (a macro you wrap around all the forms in a given .el file). Sometimes, when you avoid solutions for political reasons, you end up with something worse for political reasons. <sigh> Sometimes the world is frustrating.

agumonkey 12y ago
Don't be too stiff, having a working hack is a good thing, it helps discussions with concrete examples and usages. Hopefully if things start to move, 'cleaner' solutions will be picked.
malabarba 12y ago
I understand your feelings, but I'm not avoiding anything. :-) I wrote a compliant solution instead of spending my time begging for something else.

teddyh 12y ago

I think I’d prefer it if the symbols to be prefixed with a namespace required a :: instead of having to prefix every external call with ::. I.e. I would prefer (require 'externalpackage) (define-namespace thispackage- (defvar ::foo "yow") ; foo is explicitly local, and ; since it is short, an extra ; "::" does not make much ; difference (externalpackage-frobnicate ::foo) ; frobnicate is external ) to this, which is how the package works currently: (require 'externalpackage) (define-namespace thispackage- (defvar foo "yow") ; Some things like defvar ; magically don’t need :: (::externalpackage-frobnicate foo) ; Ugly, and I need to do this ; for *every* non-local symbol, ; making them even longer! )

malabarba 12y ago
No, you don't need to do that for every non non local symbol. You only need to do that for external symbols which are shadowed by a local symbol (which has never happened to me so far).