Re: Proper namespaces in Elisp

[Daniel Colascione]

On 5/9/20 11:30 AM, Andrea Corallo wrote:
> Daniel Colascione <address@hidden> writes:
>
> > On May 9, 2020 10:25:13 AM Andrea Corallo <address@hidden> wrote:
> >
> > > Daniel Colascione <address@hidden> writes:
> > >
> > > > On May 9, 2020 1:37:16 AM Andrea Corallo <address@hidden> wrote:
> > > >
> > > > > Daniel Colascione <address@hidden> writes:
> > > > >
> > > > > > So there are three basic operations we can support: in Python syntax,
> > > > > > 1) from PKG import * (exposing PKG.foo as foo), 2) import PKG as p
> > > > > > (exposing PKG.foo as p.foo) and 3), from PKG import foo (exposing
> > > > > > PKG.foo as foo).  CL supports all three. I'm most interested in
> > > > > > supporting #2, since that's closest to existing use. The lexspace
> > > > > > prototype posted earlier today supports #3 and #1 (the latter via
> > > > > > lexspace inheritance) only, but I think we should do #2 instead
> > > > >
> > > > > I suspect we'll need all threes anyway.
> > > >
> > > > Why? What problem is actually being solved by #1 and #3? If the
> > > > problem is that package names long enough to avoid collisions are too
> > > > annoying to type, we can address this problem with #2.
> > >
> > > I think #1 would be the way to derive an entire package and add some
> > > functionality to it without changing the names that you'll finally want
> > > to re-expose.  Is this correct?
> >
> > Can you give a concrete example of a situation in which it'd be useful
> > to do that? I think other people on the thread are right about
> > discouraging bulk naked symbol imports.
>
> Say we have a library exposing functions A B C D ... Z and you want to
> make a package that is exaclty the same except for functions F and G.
> You'd import everything (or what you need with #3) and (re)define your F
> and G versions of it.

When does this situation ever actually come up? And why should we pick 
an approach that incurs runtime overhead everywhere just for this?