From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,27af4b26a20589ec
X-Google-Attributes: gid103376,public
From: Samuel Mize <smize@imagin.net>
Subject: Re: with'ing a "foreign" package or subsystem
Date: 1999/03/01
Message-ID: <7beg6a$2o4d@news1.newsguy.com>#1/1
X-Deja-AN: 450031910
References: <m3g17qcc3u.fsf@mheaney.ni.net>
Organization: ImagiNet Communications, Ltd.
User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2)
Newsgroups: comp.lang.ada
Date: 1999-03-01T00:00:00+00:00
List-Id: <comp.lang.ada>

Matthew Heaney <matthew_heaney@acm.org> wrote:
> Can both packages coexist in the same application?  Is there a way to
> give a package a "virtual" subsystem, to prevent name-space conflicts
> like this?  Something like:
> 
> package ACME.Stacks renames <ACME company's "Stacks">;

I assume you would also change the name of ACME's Stacks, so your
Stacks and ACME's Stacks would no longer collide.

Having done that, you may as well just use the altered name.  Won't you
have to rework the code that uses them just as much either way?

OLD                : NAME-CHANGED            : RENAMED
                   :                         :
with Stacks;       : with ACME_Stacks;       : with ACME.Stacks;
procedure A is     : procedure A is          : procedure A is
  V: Stacks.Type;  :   V: ACME_Stacks.Type;  :   V: ACME.Stacks;
  use Stacks;      :   use ACME_Stacks;      :   use ACME.Stacks;

Did I miss something here?  I'm not trying to give a smart-ass reply,
I honestly don't see where you're heading.

On one other hand, if the renaming you show works, it could be an
intermediate step in getting the namespace problem corralled with
parent packages (subsystems).

On the other other hand, I don't see why it's more work to just make
it a child package of ACME in one step.

> In any case, what is the intended mechanism for resolving library-level
> name-space conflicts?

Doctor, it hurts when I do this...

I'd say parent packages defining independent name-spaces is the
intended mechanism for preventing conflicts.  To resolve them after
they occur, I think you just have to bite the bullet and rename one
of them.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam