with'ing a "foreign" package or subsystem

with'ing a "foreign" package or subsystem

[Matthew Heaney]

Suppose my company and another company are collaborating on building a
large software system written in Ada.  We each go off and separately
build the subsystems we're responsible for, and then come together some
time later for system integration.

During development, I needed a stack, and I implemented the following
package:

generic
  type Item_Type is private;
package Stacks is ...;

and my company has been using it for a while.

But come integration time, the other company (call them ACME) had also
written package Stacks, but with a different interface, and they're
using their version of Stacks everywhere.

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 seem to recall reading something like this in the Ada95 Rationale, but
don't know if any vendor has actually provided such a mechanism.  

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

Curious,
Matt

Re: with'ing a "foreign" package or subsystem

[nabbasi]

In article <m3g17qcc3u.fsf@mheaney.ni.net>, Matthew says...
 
>In any case, what is the intended mechanism for resolving library-level
>name-space conflicts?
 
This is a good question. I was thinking about this problem yesterday.
In Java, they solved this on day one by having a convention of 
naming packages based on domain name of company. (private person can make 
up their own domain name I guess.

So a package from ACM, group RD, will be called  com.acm.rd.packageName.

But offocurse in Java this is done simply by having a directory packageName
under some tree  com/acm/rd/ . In Ada package names have nothing to do
with directory structure.

If I am writing a package now, what can I do to make sure its name in unique?

Actually this can be really a problem, becuase If I build
program, depending on which package of that name it finds 'first', in
its search path, it will use.  So by changing the -I order for gnatmake,
one could end up using the other package than the first without
knowing it. (offcourse the change of having 2 packages with same name and
exactly same interface is low, but it can happen).

so If I do

gnatmake -I../dir1 -I../dir2  mymain.adb

and in dir1 and dir2  there is a stack package with same name and interfaces
but different implementation, the one in dir1/ is used. flip the -I order,
and the one in dir2/ is used. 

So, I guess you can solve this problem for now by making the search path 
such that it will see your stack package before the other one. 
If you decide to use the other stack package, switch the order.

So, do:

gnatmake -I$PATH_TO_OUR_COMPANY_STUFF -I$PATH_TO_THE_OTHER_COMPANY_STUFF \
         main.adb

This way, you always sure you'll use your stack :)

Nasser
 

Re: with'ing a "foreign" package or subsystem

[Samuel Mize]

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

Re: with'ing a "foreign" package or subsystem

[robert_dewar]

In article <m3g17qcc3u.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Suppose my company and another company are collaborating
> on building a large software system written in Ada.  We
> each go off and separately build the subsystems we're
> responsible for, and then come together some
> time later for system integration.
>
> During development, I needed a stack, and I implemented
> the following package:
>
> generic
>   type Item_Type is private;
> package Stacks is ...;
>
> and my company has been using it for a while.
>
> But come integration time, the other company (call them
> ACME) had also written package Stacks, but with a
> different interface, and they're
> using their version of Stacks everywhere.
>
> Can both packages coexist in the same application?

No!

And the trouble you are in reflects a fundamental mistake
in how you proceeded. If you are sharing a global name
space with someone, you MUST negotiate how this name
space will be used in advance, or of course you will
get into a mess.

In the case of Ada 95, it is *easy* to avoid such a mess.
It is clear that package Stacks in both cases should have
been a child package, since it was not part of the agreed
global spec between you. You should each have agreed to
a global top level utility package name, and put all your
stuff under that name.

As an example, when you use GNAT, providing you have not
used the package name GNAT, then you can use all the GNAT
provided special packages with no worry about name
conflicts.

I would be strongly opposed to implementing the kind of
kludge solution to this mess that you propose. The proper
way to fix a mess is to clean it up!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: with'ing a "foreign" package or subsystem

[Nick Roberts]

All my library units (almost all) are under the umbrella "ThoughtWing"
package.  If ACME had named its Stacks "ACME.Stacks" in the first place, and
you had named yours "Matt.Stacks", there would have been no problem.

I guess a new pragma might just possibly help, e.g.:

   pragma Incorporate_Library (Base_Package => ACME, External_Location =>
"acme.stuff");

which adds the library (be it in source form, intermediate form, or
whatever) in directory/project "acme.stuff" to the current library, but as
if every unit 'x' were named "ACME.x" (and implicitly declaring an empty
package 'ACME').

Another one for Ada 200X?  These ideas are building up!

-------------------------------------
Nick Roberts
-------------------------------------

Re: with'ing a "foreign" package or subsystem

[Ehud Lamm]

On Mon, 1 Mar 1999, Nick Roberts wrote:

> All my library units (almost all) are under the umbrella "ThoughtWing"
> package.  If ACME had named its Stacks "ACME.Stacks" in the first place, and
> you had named yours "Matt.Stacks", there would have been no problem.

I so this in so many places, that it is included as one of the idioms on
my idioms page!

http://www2.cybercities.com/e/ehud/ada/idioms.html

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: with'ing a "foreign" package or subsystem

[dennison]

In article <m3g17qcc3u.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Suppose my company and another company are collaborating on building a
> large software system written in Ada.  We each go off and separately
> build the subsystems we're responsible for, and then come together some
> time later for system integration.
>
> During development, I needed a stack, and I implemented the following
> package:
>
> generic
>   type Item_Type is private;
> package Stacks is ...;
>
> and my company has been using it for a while.
>
> But come integration time, the other company (call them ACME) had also
> written package Stacks, but with a different interface, and they're
> using their version of Stacks everywhere.
>
> 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:
>

For some reason, the above reminds me very strongly of the intro to "The Odd
Couple". :-)


> package ACME.Stacks renames <ACME company's "Stacks">;
>
> I seem to recall reading something like this in the Ada95 Rationale, but
> don't know if any vendor has actually provided such a mechanism.

The only options I can see are to either rename one (or both) packages and
all references to them, or to rename *every* package to be a child of the
"company" package like you suggest above. Personally, I'd go for the first
(or try to unify them).

But I'm sure you knew about both of those options.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: with'ing a "foreign" package or subsystem

[dennison]

In article <m3g17qcc3u.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Suppose my company and another company are collaborating on building a
> large software system written in Ada.  We each go off and separately
> build the subsystems we're responsible for, and then come together some
> time later for system integration.
>
> During development, I needed a stack, and I implemented the following
...
> But come integration time, the other company (call them ACME) had also
> written package Stacks, but with a different interface, and they're
> using their version of Stacks everywhere.
>
> 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:
>

For some reason, the above reminds me very strongly of the intro to "The Odd
Couple". :-)


> package ACME.Stacks renames <ACME company's "Stacks">;
>
> I seem to recall reading something like this in the Ada95 Rationale, but
> don't know if any vendor has actually provided such a mechanism.

The only options I can see are to either rename one (or both) packages and
all references to them, or to rename *every* package to be a child of the
"company" package like you suggest above. Personally, I'd go for the first
(or try to unify them).

But I'm sure you knew about both of those options.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: with'ing a "foreign" package or subsystem

[dennison]

In article <7bcp7l$1qr@drn.newsguy.com>,
  nabbasi@pacbell.net.NOSPAM wrote:

> If I am writing a package now, what can I do to make sure its name in unique?

Well, communicating with the other developers on your program would be a good
start. :-)

On STGT, where we had over a hundred developers, each CSCI (subsystem) in the
system had its own designator which had to go on the front of the package
name. That reduced the problem to simply communicating with the other
developers in your CSCI.

This particular case is a bit worse than that, though. Aside from the naming
problem, it seems the packages were created to serve the same purpose. Having
a subsystem devoted to reusable and reused code helps a lot with this type of
problem. It is quite likely that both groups would have realized that "Stack"
is something that belongs in the reusable subsystem. Not only would that have
prevented the namespace clash, but it also would have prevented the customer
from paying to have essentially the same package developed twice!

> Actually this can be really a problem, becuase If I build
> program, depending on which package of that name it finds 'first', in
> its search path, it will use.  So by changing the -I order for gnatmake,
> one could end up using the other package than the first without
> knowing it. (offcourse the change of having 2 packages with same name and
> exactly same interface is low, but it can happen).

I haven't tried this error with Gnat, but with other compilers this situation
got clearly flagged as an error ("can't have two units w/ same name in same
compilation", or somesuch).

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: with'ing a "foreign" package or subsystem

[dennison]

In article <7beg6a$2o4d@news1.newsguy.com>,
  Samuel Mize <smize@imagin.net> wrote:
> 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?
>
> Did I miss something here?  I'm not trying to give a smart-ass reply,
> I honestly don't see where you're heading.

I think what he's getting at (correct me if I'm wrong here Matt), is that he
wants to be able to "reveal" the first declaration of an object by renaming
the second declaration off of it.

While I think lots of use-philes would like that capability too,....YUK!

> 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.

Yeah. You're looking for a language solution to what was really a management
problem. Chalk this one up to experience, fix it, and move on.


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own