In article L1M@sugar.NeoSoft.COM, daniels@NeoSoft.com (Brad Daniels) writes:
> >
> >[... munch ...]

> >> Exactly.  But this is exactly the problem that some have identified.  It
> >> requires the library vendors to use namespaces and does not protect the
> >> customer from duplicate namespaces.
> >
> >No.  The consumer could add the name space declarations to the header files
> >himself.

> Without a pure consumer-side namespace implementation, the vendors will in
> fact need to put the namespaces in their header files unless they provide
> source to their entire library.  A provider-side namespace implementation
> would require that the library be compiled using the same namespace as the
> library consumer expects it to use.  Just editing the header files would
> achieve nothing in such a situation, and in the case of consumer-side name-
> spaces, editing header files is unnecessary.

This was addressed earlier in the thread.  To re-iterate: wrapping an object
(referring to an object in the OOP sense, not the '.o' output of the compiler)
in a namespace requires wrapping the *components* of an object in a namespace.
Since an object consists of (1) implementation, and (2) interface, the
interface and implementation must both be wrapped together.

Since vendors ship interface source code (i.e., header files) anyway, wrapping
the *interface* is trivial, and could easily be done by the consumer.

Wrapping the *implementation*, on the other hand, is not quite as trivial.
Basically, you must either wrap the source (which, if the consumer is to do
the wrapping, would require vendors to ship source code to the implementation),
or you must have some other mechanism to wrap it....

...such as a modified linker that would allow something like:

ld -NM someNameSpace libVenderA.a -NM otherNameSpace libVenderB.a

> In my opinion, if namespaces aren't going to be consumer-side things,
> they're not worth the baggage.

I agree, but I admit I still haven't read Bjarne Stroustrup's original proposal.
I intend to soon.

Nevin

In article <23rdp5$dsb@cnn.sim.es.com>, npratt@madmax.modsys (Nevin Pratt) writes:
|> In article 24765@cdf.toronto.edu, g2devi@cdf.toronto.edu (Deviasse Robert N.) writes:
|>
|> > I'm not really convinced that this linker approach would work, not that I
|> > wouldn't want it to. The problem has to do with include files and the fact that
|> > they don't always commute with namespaces. Consider the following example:
|>
|> [ excellent example deleted...]
|>
|> Good point.
|>
|> Looks like vendors would have to ship their header files :-),
|> and the namespace wraps would go there (in the header files) rather than
|> wrapping the #include directive.
|>
|> Nevin

Exactly.  But this is exactly the problem that some have identified.  It
requires the library vendors to use namespaces and does not protect the
customer from duplicate namespaces.

Both problems can be partially solved through the use of conventions.  If,
by convention, vendor-supplied libraries were always enclosed in a
namespace labeled with the vendor's name, then namespace collisions would
be very rare.  The market would tend to enforce this convention by
rejecting libraries that didn't adhere to it.  Another solution, although
probably less likely or desirable is to have a central registry of
namespaces.  Vendor's would have to register their namespace names to
assure uniqueness.


By the way, this problem is inheritted from C and stems from reliance on
the preprocessor inclusion mechanism for importing interfaces.  In
Borland's object-oriented Pascal, for example, modules are tied by name to
their object files.  The interface and the implementation are tied together
in a two-part object file.  The compiler reads the interface from the same
file that the linker reads the code.  Thus, by importing module, you
compile in information that can be used by the linker to find the
correct object file.  C and C++'s #include mechanism leaves no
language-defined connection between an interface file name, implementation
source file name and object file name.  Thus, the compile-time namespaces
can only be resolved at link time by user convention, not by the language
or even the environment.

Imagine if the namespace concept looked more like this (THIS IS NOT A
PROPOSAL):

------------
att/String.h
------------
namespace String : "att/String.a" {
  ...
}

-----------
HP/String.h
-----------
namespace String : "HP/String.a" {
  ...
}

------
main.C
------

#include "att/String.h"
#include "HP/String.h"

void foo()
{
  using namespace String; // Finds first String (in att/String.a)
  String a;   // String from att library;
  ...
}

void bar()
{
  using namespace String : "HP/String.a"; // Finds String in HP/String.a
  using namespace AttString = String : "att/String.a";
  String b;     // String from HP library
  AttString::String c;    // String from att library
  ...
}

A drawback to the above, of course, is that it requires the use of
system-specific file names.  However this would only be needed in cases of
conflict, which should be rare, and is not unlike the current distinction
between:
  #include "time.h"
  #include "sys/time.h"

Alas, I think C++ has too much C baggage to every have a true module
concept, so I don't think the above will every be refined into an
acceptible proposal.
--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
-------------------------------------------------------------------------

In article 4779@hpwala.wal.hp.com, pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:

[... munch ...]

> |> Good point.
> |>
> |> Looks like vendors would have to ship their header files :-),
> |> and the namespace wraps would go there (in the header files) rather than
> |> wrapping the #include directive.
> |>
> |> Nevin
>
> Exactly.  But this is exactly the problem that some have identified.  It
> requires the library vendors to use namespaces and does not protect the
> customer from duplicate namespaces.

No.  The consumer could add the name space declarations to the header files
himself.

Nevin

In article <252uk7$43n@cnn.sim.es.com> npratt@madmax.modsys writes:
>In article 4779@hpwala.wal.hp.com, pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
>
>[... munch ...]
>
>> |> Good point.
>> |>
>> |> Looks like vendors would have to ship their header files :-),
>> |> and the namespace wraps would go there (in the header files) rather than
>> |> wrapping the #include directive.
>> |>
>> |> Nevin
>>
>> Exactly.  But this is exactly the problem that some have identified.  It
>> requires the library vendors to use namespaces and does not protect the
>> customer from duplicate namespaces.
>
>No.  The consumer could add the name space declarations to the header files
>himself.
>
>Nevin

Without a pure consumer-side namespace implementation, the vendors will in
fact need to put the namespaces in their header files unless they provide
source to their entire library.  A provider-side namespace implementation
would require that the library be compiled using the same namespace as the
library consumer expects it to use.  Just editing the header files would
achieve nothing in such a situation, and in the case of consumer-side name-
spaces, editing header files is unnecessary.

In my opinion, if namespaces aren't going to be consumer-side things,
they're not worth the baggage.

That said, it seems to me that a consumer-side namespace implementation
is going to start forcing some strong requirements on how header and object
files relate to each other.  In my mind, that would be goodness, but it
might make for some serious hassles from a compatibility standpoint...

- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad I was born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

npratt@madmax.modsys (Nevin Pratt) writes:

>In article 4779@hpwala.wal.hp.com, pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:

>[... munch ...]

>> |> Good point.
>> |>
>> |> Looks like vendors would have to ship their header files :-),
>> |> and the namespace wraps would go there (in the header files) rather than
>> |> wrapping the #include directive.
>> |>
>> |> Nevin
>>
>> Exactly.  But this is exactly the problem that some have identified.  It
>> requires the library vendors to use namespaces and does not protect the
>> customer from duplicate namespaces.

>No.  The consumer could add the name space declarations to the header files
>himself.
>
>Nevin
>

Wouldn't it be a good idea to treat a library as if it was an object and
use the scope operator(::) to resolve scope?

Alain Lauzon
vr@altitude.cam.org

In article 24765@cdf.toronto.edu, g2devi@cdf.toronto.edu (Deviasse Robert N.) writes:

> I'm not really convinced that this linker approach would work, not that I
> wouldn't want it to. The problem has to do with include files and the fact that
> they don't always commute with namespaces. Consider the following example:

[ excellent example deleted...]

Good point.

Looks like vendors would have to ship their header files :-),
and the namespace wraps would go there (in the header files) rather than
wrapping the #include directive.

Nevin

In article 93Jul28184156@slsvhdt.us-es.sel.de, kanze@us-es.sel.de (James Kanze) writes:
> In article <1993Jul25.122004.9305@ucc.su.OZ.AU>
> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
> |> In article <KANZE.93Jul22141247@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>
> |> >In fact, because of its low level approach, the current namespace
> |> >proposal forces a reworking of much of the core language in the
> |> >working draft, which will result in a corresponding delay of the
> |> >standard, without really buying us that much.
>
> |> I dont agree: first, namespaces are necessary for programming
> |> in the large to support multi-vendor library integration.
>
> I don't think they are necessary.  Unique prefixes on all externally
> visible names are a perfectly viable solution for this problem.  Of
> course, some vendors don't use such prefixes.  And what makes you
> think these vendors will use namespaces?

What authority exists to guarantee that the vendors would choose
unique prefixes?  None?  I thought not.

No, the "unique prefixes" solution doesn't solve the name space problem--
it merely reduces the likelihood of a name collision.

Also, if I understand the namespace proposal properly, the use of
namespaces is done by the consumer code-- it is not done by the supplier
code.  In other words, venders don't use namespaces, but rather the
purchasers of the venders' objects will use namespaces to distinguish
between the wares of different venders.

For example:

      namespace venderA {
          #include <somepath/String.h>       // define Vender A's String class
      }

      namespace venderB {
          #include <differentpath/String.h>  // define Vender B's String class
      }

      int main()
      {
          using namespace venderA;
          String aString;
          aString->doSomething();

          using namespace venderB;
          String bString; // I could even have used 'aString' again if I wanted
          bString->doSomethingDifferent();
      }


In the code above, I, as a consumer, am consuming (using) the "String" class
from two different suppliers (venders)-- an obvious name collision problem
if we don't have namespaces, but its working just fine, thanks.

Also, if my code is later "consumed" by somebody elses code (where I
am now the vender/supplier instead of just the consumer), they can wrap
my stuff within a namespace of their own choosing, and there
will never be a collision of namespace names because the namespace names
"venderA" and "venderB" are not exported, so they are not visible to
anybody that consumes my code.

Nevin

P.S. If I am wrong, and it turns out that the namespaces must be
specified by the supplier, then Bjarne's namespace proposal is
dead in the water as far as I'm concerned, and John Max Skaller's
post above is legitimate, and I take all my words back.  Namespace
control is a *consumer* side problem, not a supplier-side problem.

>Also, if I understand the namespace proposal properly, the use of
>namespaces is done by the consumer code-- it is not done by the supplier
>code.  In other words, venders don't use namespaces, but rather the
>purchasers of the venders' objects will use namespaces to distinguish
>between the wares of different venders.
>
>P.S. If I am wrong, and it turns out that the namespaces must be
>specified by the supplier, then Bjarne's namespace proposal is
>dead in the water as far as I'm concerned, and John Max Skaller's
>post above is legitimate, and I take all my words back.  Namespace
>control is a *consumer* side problem, not a supplier-side problem.
>

 Namespaces affect the mangled names in object files.
If a vendor supplies object files, the namespaces used
must be supplied by the vendor. The user must use those spaces.

 If the vendor supplies source, the user can wrap
the code in namespaces.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> Namespaces affect the mangled names in object files.
>If a vendor supplies object files, the namespaces used
>must be supplied by the vendor. The user must use those spaces.

This is true if a conventional Unix or Unix-like linker is used.  There
would seem to be no great technical barrier to building a linker that has
an option that effectively causes all exported symbols defined in a
library to be treated as if they had been declared in a namespace.



--
Joe Buck jbuck@ohm.EECS.Berkeley.EDU

>>>Also, if I understand the namespace proposal properly, the use of
>>>namespaces is done by the consumer code-- it is not done by the supplier
>>>code.  In other words, venders don't use namespaces, but rather the
>>>purchasers of the venders' objects will use namespaces to distinguish
>>>between the wares of different venders.
>>>
>>>Namespace control is a *consumer* side problem, not a supplier-side problem.
>>
>> Namespaces affect the mangled names in object files.
>>If a vendor supplies object files, the namespaces used
>>must be supplied by the vendor. The user must use those spaces.
>>
>> If the vendor supplies source, the user can wrap
>>the code in namespaces.

> This is true if a conventional Unix or Unix-like linker is used.  There
> would seem to be no great technical barrier to building a linker that has
> an option that effectively causes all exported symbols defined in a
> library to be treated as if they had been declared in a namespace.

This sounds right to me.

It would seem to me that, for the consumer to be able to specify the
namespace, and assuming that the consumer doesn't have the suppliers source
code, then we MUST somehow tell the linker what namespace a given '.o' or
'.a' file is in.  Therefore, the linker MUST be modified to support this:

% ld MyProg.o -nm VenderA venderAlib.a -nm VenderB venderBlib.a

Without this necessary linker support, then the namespace information must
already exist in the '.a' (or '.o') before the linker gets the file, which
means that the person compiling the source code would also specify the
namespace for that code.  This in turn would mean that if the consumer is
to be able to specify the namespace, the vender (supplier) must ship source
code.  And, I've already said that if the vender specifies the namespace,
we haven't solved anything.  The namespaces must be specifiable by
the consumer, IMO.

So, we either modify the linker to support namespace declarations on the
link line (like the example above), or venders must ship source code, or
we live without real namespace control.

In my opinion, the only real alternative is to modify the linker.

Nevin

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

[someone else writes:]

>>P.S. If I am wrong, and it turns out that the namespaces must be
>>specified by the supplier, then Bjarne's namespace proposal is
>>dead in the water as far as I'm concerned, and John Max Skaller's
>>post above is legitimate, and I take all my words back.  Namespace
>>control is a *consumer* side problem, not a supplier-side problem.
>
> Namespaces affect the mangled names in object files.
>If a vendor supplies object files, the namespaces used
>must be supplied by the vendor. The user must use those spaces.

Yes, but it should be possible to provide a tool to
rename the symbols in an object file so that they can
be repackaged into a different namespace.
I don't even think that it would be particularly difficult.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <23p4to$9sm@cnn.sim.es.com> npratt@madmax.modsys writes:
>>>>Also, if I understand the namespace proposal properly, the use of
>>>>namespaces is done by the consumer code-- it is not done by the supplier
>>>>code.  In other words, venders don't use namespaces, but rather the
>>>>purchasers of the venders' objects will use namespaces to distinguish
>>>>between the wares of different venders.
>>>>
>>>>Namespace control is a *consumer* side problem, not a supplier-side problem.
>>>
>>> Namespaces affect the mangled names in object files.
>>>If a vendor supplies object files, the namespaces used
>>>must be supplied by the vendor. The user must use those spaces.
>>>
>>> If the vendor supplies source, the user can wrap
>>>the code in namespaces.
>
>> This is true if a conventional Unix or Unix-like linker is used.  There
>> would seem to be no great technical barrier to building a linker that has
>> an option that effectively causes all exported symbols defined in a
>> library to be treated as if they had been declared in a namespace.
>
>This sounds right to me.
>
>It would seem to me that, for the consumer to be able to specify the
>namespace, and assuming that the consumer doesn't have the suppliers source
>code, then we MUST somehow tell the linker what namespace a given '.o' or
>'.a' file is in.  Therefore, the linker MUST be modified to support this:
>
>% ld MyProg.o -nm VenderA venderAlib.a -nm VenderB venderBlib.a
>
>Without this necessary linker support, then the namespace information must
>already exist in the '.a' (or '.o') before the linker gets the file, which
>means that the person compiling the source code would also specify the
>namespace for that code.  This in turn would mean that if the consumer is
>to be able to specify the namespace, the vender (supplier) must ship source
>code.  And, I've already said that if the vender specifies the namespace,
>we haven't solved anything.  The namespaces must be specifiable by
>the consumer, IMO.
>
>So, we either modify the linker to support namespace declarations on the
>link line (like the example above), or venders must ship source code, or
>we live without real namespace control.
>
>In my opinion, the only real alternative is to modify the linker.
>
>Nevin
>

I'm not really convinced that this linker approach would work, not that I
wouldn't want it to. The problem has to do with include files and the fact that
they don't always commute with namespaces. Consider the following example:

=======
File1.h
=======
#ifndef __FILE1_H
#define __FILE1_H
    #include <iostream.h>
    // ...
#endif

=========
main.cpp
=========

namespace VendorA {
    #include "File1.h"
};
#include <iostream.h>

int main(){
   cout << "Hello world" << endl ;             // Error cout not defined?????
   VendorA::cout << "Hello world" << endl ;    // Compiles but doesn't link???
   // ...
   return 0;
}

==========================================

The problem with the above is that since cout is included in the
VendorA namespace and so it has the signature of this namespace.

There are work arounds. If "iostream.h" were included before "File1.h" then
there would be no problem. But this is a simple example, in a more complex
example, ensuring that the include file order is right can be a real challenge.

On top of this, suppose you have some libraries that use "File1.cpp" as is
while other's change add a namespace qualifier, you'll really have a mess.

Namespaces might be syntactical sugar, but they are much needed syntactical
sugar. Sure using the prefix as MS_ will have (almost) the same effect as
using the MS namespace, but that's not the point. Prefixes tend to be short
since one has little choice in accepting them and all code in the library
is prefixed with MS_. Thus if MicroSoft and MegaSoft both have libraries,
there is a good chance that both will use the same prefix. Namespaces give
clients the *choice* of how long the prefix they wish and thus would tend
to be as long possible, which means that the chance of collision will be
much lower.

(BTW, if you think that namespace identifiers will be short, any wagers that
      we won't see namespaces like the following?

   namespace FooBar_Software_Inc_V3_Copywrite_1994__The_world_leader_in_OOP {
     // ...
   };

OR
   namespace FooBar_Software_Inc__Consider_buying_our_other_quality_software {
     // ...
   };


:-(

)


Take care
    Robert
--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

g2devi@cdf.toronto.edu (Deviasse Robert N. @ University of Toronto Computing Disciplines Facility) writes

 > (BTW, if you think that namespace identifiers will be short, any wagers that
 >       we won't see namespaces like the following?
 >
 >    namespace FooBar_Software_Inc_V3_Copywrite_1994__The_world_leader_in_OOP {
 >      // ...
 >    };
 >
 > OR
 >    namespace FooBar_Software_Inc__Consider_buying_our_other_quality_software {
 >      // ...
 >    };
 >
 > :-(
 >
 > )

I'm sure we will see names that are too long to be convenient to use. Dealing with those
is one purpose of namespace aliases:

 namespace Flib = FooBar_Software_Inc_V3_Copywrite_1994__The_world_leader_in_OOP;

 // ...

 Flib::f(2); // meaning FooBar_Software_Inc_V3_Copywrite_1994__The_world_leader_in_OOP::f(2)

In <comp.std.c++> rme@olympia.miro.com (Richard Emberton) writes:
>
>Second, why use the term "namespace". A vendor who organizes their library
>product does not organize in a namespace, rather they package it. So, why not
>just call it "package". Yes, namespace is low-level, computer science-ish
>while package is higher-level, application/software engineering-ish, ...

That is indeed the reason.

    -- Dag

In article <1993Jul19.135403.24096@miro.com> rme@olympia.miro.com
(Richard Emberton) writes:

|> I've just finished reading Stroustrup's namespace proposal and I've got a
|> a correction and a question.

|> First, rather than say that Ada's package mechanism is similar to the namespace
|> proposal, say that the namespace proposal is similar to the Ada package
|> mechanism. If I am not mistaken, Ada packages existed before the namespace
|> proposal.

I have been led to believe that Ada's package mechanism is closer to a
Modula-2 module that to the C++ namespace proposal.

In particular, generic types are handled by packages (a generic
package).  There is no intrinsic link between templates and
namespaces.

In fact, because of its low level approach, the current namespace
proposal forces a reworking of much of the core language in the
working draft, which will result in a corresponding delay of the
standard, without really buying us that much.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In <comp.std.c++> kanze@us-es.sel.de (James Kanze) writes:
>
>In fact, because of its low level approach, the current namespace
>proposal forces a reworking of much of the core language in the
>working draft, which will result in a corresponding delay of the
>standard, without really buying us that much.

It would be instructive if you gave us some examples of what must be
reworked in the core language.

`namespace' was chosen for several reasons. One was indeed that using `scope'
would have led to too many clashes with identifiers in existing code; it would
also have led to confusion when talking about progrms because many scopes are not
namespaces. Choosing `package' would have led to confusion because some people
would have (quite reasonably) assumed that a `C++ package' mechanism would have
been similar to, say, the Ada package mechanism in detail, and namespaces are not.

In article <22m60k$q0g@nic.lth.se> dag@control.lth.se (Dag Bruck)
writes:

|> In <comp.std.c++> kanze@us-es.sel.de (James Kanze) writes:

|> >In fact, because of its low level approach, the current namespace
|> >proposal forces a reworking of much of the core language in the
|> >working draft, which will result in a corresponding delay of the
|> >standard, without really buying us that much.

|> It would be instructive if you gave us some examples of what must be
|> reworked in the core language.

Anything to do with name binding, for a start.  And in C++, this is a
critical point, since the language is so context dependant.  (Syntax
can actually depends on what a name is bound to.)

I know that Bjarne has done a lot of work on namespaces, and tried to
cover the core issues in his proposal, but he is not omniscient, and
until we've actually gone through the core (once more) with a fine
toothed comb, we don't really know how big the impact will be.  (My
gut feeling is that it will be more than exceptions, but less than
templates.) Do you really think that the namespaces proposal will have
no impact on the core language?

Just to make things clear: I think that Bjarne has done a good job on
the namespaces proposal.  He has certainly put a lot of work in it.  I
personally feel that something more along the lines of modules would
be better, but I haven't studied the issues, and could be wrong.  The
problem is that there isn't time to study the issues *and* get the
standard out on time.  Any proposal of such scope (namespaces, the new
casts, etc.) need a certain time to "settle in", in which people
simply become aware of them, and start to think about the
implications.  The real problems with the namespace proposal will only
really begin to appear a year (or more) from now, when compiler
writers start trying to implement it.  And when, according to the
current schedule, the C++ standard will be in the public draft phase,
and any significant changes in it will have become much more difficult
to make.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.93Jul22141247@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>
>In fact, because of its low level approach, the current namespace
>proposal forces a reworking of much of the core language in the
>working draft, which will result in a corresponding delay of the
>standard, without really buying us that much.

I dont agree: first, namespaces are necessary for programming
in the large to support multi-vendor library integration.

Secondly, namespaces provide a focus for lookup issues, and far from
delaying the standard may well allow these issues to be systematically
and uniformly handled.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

Would anybody care to post the namespace proposal or a summary
of it here?


--
Christopher Barber
(cbarber@bbn.com)

In article <1993Jul25.122004.9305@ucc.su.OZ.AU>
maxtal@physics.su.OZ.AU (John Max Skaller) writes:

|> In article <KANZE.93Jul22141247@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:

|> >In fact, because of its low level approach, the current namespace
|> >proposal forces a reworking of much of the core language in the
|> >working draft, which will result in a corresponding delay of the
|> >standard, without really buying us that much.

|> I dont agree: first, namespaces are necessary for programming
|> in the large to support multi-vendor library integration.

I don't think they are necessary.  Unique prefixes on all externally
visible names are a perfectly viable solution for this problem.  Of
course, some vendors don't use such prefixes.  And what makes you
think these vendors will use namespaces?

Note that I'm not saying that namespaces are of no use, just that they
won't solve all of the problems, and while they may or may not be a
nice feature, they certainly are not *necessary*.

|> Secondly, namespaces provide a focus for lookup issues, and far from
|> delaying the standard may well allow these issues to be systematically
|> and uniformly handled.

Namespaces do not replace any of the current scoping rules, so they
cannot simplify things.  But even if they could, the problem is
elsewhere.  People have been thinking about and using the current
situation for some years now.  We know the problems (more or less),
and are making headway on solutions to them.  By adding namespaces, we
move back to square zero, or close to it.  Roughly speaking, we
replace a four year project that is 75% finished, with a three year
project we haven't started on.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <CAzJyJ.GEr@cbnewsk.cb.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes:
>< From: kanze@us-es.sel.de (James Kanze)
>< close to it. Roughly speaking, we replace a four year project that is 75%
>< finished, with a three year project we haven't started on.
>
>Unfortunately, the latter 25% of that 4 year project had approximately a 0%
>chance of being completed in time, or ever. Yes, people have been thinking

 Schedule is to complete in 1 year, that is, three more meetings,
where complete means release to SC22 as a committee draft. That
does not mean changes cannot be made right up to scheduled determination
as an International Standard, but those changes have to be more
and more like clarifications than anything major.

 IMHO that is possible. More likely perhaps is a one meeting
slippage. Progress at the moment in accelerating towards the target.
However, James suggestion of a three YEAR delay seems extremely
pessimistic to me.

 I'd be extremely surprised if the delay is more than one year.
The only way I can envisage a major slippage is if the WP is released to
(SC22) committee stage too early, and is rejected and the whole process
has to be restarted.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

James Kanze (kanze@us-es.sel.de) wrote:
: In article <1993Jul25.122004.9305@ucc.su.OZ.AU>
: maxtal@physics.su.OZ.AU (John Max Skaller) writes:

: |> In article <KANZE.93Jul22141247@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:

: and are making headway on solutions to them.  By adding namespaces, we
: move back to square zero, or close to it.  Roughly speaking, we
: replace a four year project that is 75% finished, with a three year
: project we haven't started on.
huh?  You can still use the old solutions.  Just becuase namespaces exist
there is no reason why unique prefixes can't be used!!
: --
: James Kanze                             email: kanze@us-es.sel.de
: GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
: Conseils en informatique industrielle --
:                    -- Beratung in industrieller Datenverarbeitung
   Michael HUnter

I've just finished reading Stroustrup's namespace proposal and I've got a
a correction and a question.

First, rather than say that Ada's package mechanism is similar to the namespace
proposal, say that the namespace proposal is similar to the Ada package
mechanism. If I am not mistaken, Ada packages existed before the namespace
proposal.

Second, why use the term "namespace". A vendor who organizes their library
product does not organize in a namespace, rather they package it. So, why not
just call it "package". Yes, namespace is low-level, computer science-ish
while package is higher-level, application/software engineering-ish, but why
is it being proposed? Its being proposed to help oranize code, lots of code
not a little bit of code. So, why not use a term that fits the domain and
problem area being targetted. What makes more sense, "Hey, boss should I
organize our code into a namespace?" or "Hey, boss should I organize our code
into a package?" What would marketing say, "Our code is namespaced" or "Our
code is packaged"? So what if Ada used it first, so what. Namespace, while
accurate, does not correctly reflect the most important and most needed use
of such a mechanism - the high-level organization of large amounts of code and
people do not refer to such code as namespaces.

Richard Emberson
rme@MIRO.COM