[Top][All Lists]

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

Re: Proper namespaces in Elisp

From: Andrea Corallo
Subject: Re: Proper namespaces in Elisp
Date: Sat, 09 May 2020 11:30:30 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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.


reply via email to

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