Eli Zaretskii <eliz@gnu.org> writes: >> From: Matt Armstrong <matt@rfc20.org> >> Cc: emacs-devel@gnu.org >> Date: Tue, 22 Nov 2022 10:01:33 -0800 >> >> I think there is another drawback of Emacs' prefix based namespace >> convention: that of longer local (private, non-public, unexported, etc.) >> names. > > Why is that a drawback? (It's a serious question.) Thanks for asking. I have to admit that my answer boils down to familiarity. I'd like programming in Emacs Lisp to feel more like the other programming languages I'm more familiar with. When I have written Emacs Lisp packages the package name prefixes have been a bit of a chore to deal with. I'm happier programming in languages where the namespace context is a property of a scope, usually a file level context. This way, the "current" namespace need not be re-stated throughout a package's code every time a name is mentioned. This is a different concern than how code references names names from other packages. If I'm writing code that uses something from some other package, I'm fine stating that other package's name, especially if the language lets me abbreviate longer package names (usually for the local file/scope). I believe the general dislike for having to re-state the associated package within the package code itself is one reason why people write packages like https://elpa.gnu.org/packages/nameless.html. My guess is that avoiding this kind of repetitive verbosity, at least for the common cases, is what many people want to get out of "Emacs Packages/Modules". That is just a guess, though. I can't really tell what benefits people actually want when they "it'd be great if Emacs had CL style packages." I have to say that, personally, CL style packages didn't "cut it" for me either. They did make it easier to have package-private names that were boilerplate free, but they didn't make it obvious which of my symbols were exported and which weren't. That was a property of not of the symbol name, not of its `defun/defvar', but of whether it appeared in some export list somewhere else, often in a different file. I didn't think that was particularly great, either.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4