> Using a different syntax for modules, e. g.
>    c:stdio
> the problem would go away. (I do not suggest this solution)
>

Why not? I've never understood the reason for dropping :: in favour of . in Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to explicitly stipulate that something is a static method/variable (again, say in a template) how to I do it?

Is there a reason that D has done away with :: or maybe just :   ?

I think we should have the ability to specify relative and absolute namespaces, so this would certainly lead to a mess with using .

Surely there are plenty of symbols left in the character set that would make this relatively simple.

> I deliver libraries. I don't want a new library to break any old code. If a language can't gurantee me a way - however complicated - to do that, it is no use for me.

Quite true

> I think there's two mistakes going on here.  First, we should be applying package organisation to Phobos and other libraries.  Second, we should be using capital letters in module names when appropriate. Intuitively, lowercase feels better.

Agree with this ...

> Yeah, don't use too-short module names, and don't put kludges into a language solving a problem that shouldn't exist if the language were being correctly used.

.. but not with this. For a new language, that purports to address the problems of previous ones, to rely on basic functions (such as name resolution) working only if people use some ephemeral, collegial, custom, is patently absurd.

There needs to be a proper solution.

Maybe increasing orthogonality in operator use would be a start ...

Agree with a lot of this.

Can I suggest that there's a panel (perhaps of just one compiler walter) that exercises control over the namespaces, at least as far as the ones that go into Phobos, so that we don't get inconsistent, or ridiculously large, standard libraries.

IMO, one of the strongest features of C/C++ is that they've jealously guarded the small sizes of their libraries.

If there's a good, succinct, standard library with rigorous procedures to forefend bloat, and there are good mechanisms for allow robust intermixing of third-party libraries, then we'll all be happy.


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bd4s6r$1jiq$1@digitaldaemon.com...
> Windows should go into D.Platform.windows or D.SDK.windows;  it is most certainly not standard C runtime library material.  Same with Linux.
>
> I don't care if you use capital letters or not.  Personally I like MixedCase, but it really doesn't matter to me.
>
> I do like the idea of moving all this stuff into the D module umbrella. Prevents many many clashes, prevents cluttering up the global namespace.
It
> gives people a clear idea of whether a module is 1st-party or 3rd-party. But then why would Dig go under D?  DigitalMars should reserve the entire D.* module namespace.  Library writers can make their own, such as BRadons.Dig.  ;)
>
> Why the "Internal" module group?  I'm kinda surprised that there are so
many
> low-level support libraries;  I'd expect more of this to be built in, or unnecessary.
>
> What's the difference between complex math and complex arithmetic?  Why
are
> they separate?  They're not even in the same branch... that's just wierd.
>
> I agree that Intrinsic should have aliases in Math.  I suggest that users should not have to care whether something is an intrinsic or not;  this is entirely a choice that should be left up to the compiler, possibly
affected
> by some kind of speed vs. size switch.  It is an implementation detail and users shouldn't be forced to deal with it.
>
> Why is there D.Exception.* and D.Internal.Exception?
>
> Rename Conv to Convert.  Saving 3 characters is not worth it.  Or maybe Conversion.
>
> Sean
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bd1r3s$1s87$1@digitaldaemon.com...
> > Yeah, don't use too-short module names, and don't put kludges into a language solving a problem that shouldn't exist if the language were being correctly used.
> >
> > I think there's two mistakes going on here.  First, we should be applying package organisation to Phobos and other libraries.  Second, we should be using capital letters in module names when appropriate. Intuitively, lowercase feels better.  But in practice, it results in ugly names, lots of collisions, and seems to result in more curious acronyms and cut words than capitalised (java.rmi.dgc, for example). One naming scheme could be like this:
> >
> > aaA -> D.Internal.AArray;
> > achar -> D.Internal.AChar;
> > adi -> D.Internal.Array;
> > alloca -> D.Internal.alloca;
> > array -> D.Exception.ArrayBoundsError;
> > arraycast -> D.Internal.ArrayCast;
> > arraycat -> D.Internal.ArrayCat;
> > assert -> D.Exception.AssertError; (It's not even a valid module name
> > for goodness' sake!)
> > cast -> D.Internal.Cast; (Ditto!)
> > cmath -> D.System.ComplexMath;
> > cmath2 -> D.Internal.ComplexArithmetic;
> > com -> D.Phobos.COM;
> > compiler -> D.Phobos.Compiler;
> > conv -> D.Phobos.Conv;
> > crc32 -> D.Phobos.CRC32;
> > ctype -> D.Phobos.CharType;
> > date -> D.Phobos.Date;
> > dateparse -> D.Phobos.DateParse;
> > deh2 -> D.Internal.ExceptionHandling;
> > dmain2 -> D.Internal.Main;
> > file -> D.Phobos.File;
> > gc -> D.Phobos.GC;
> > gcstats (merge with gc)
> > intrinsic -> D.Internal.Intrinsic; (put aliases in D.Phobos.Math)
> > invariant -> D.Internal.Invariant;
> > iunknown -> D.Phobos.IUnknown;
> > linux -> D.CRT.Linux;
> > linuxextern -> D.CRT.LinuxExtern;
> > llmath -> D.Internal.LongArithmetic;
> > math -> D.Phobos.Math;
> > math2 (merge with D.Phobos.Math)
> > memset -> D.Internal.memset;
> > moduleinit -> D.Internal.ModuleInit;
> > obj -> D.Internal.Object;
> > object -> D.Phobos.Object;
> > outbuffer -> D.Phobos.OutBuffer;
> > outofmemory -> D.Error.OutOfMemory;
> > path -> D.Phobos.Path;
> > qsort -> D.Internal.Sort;
> > random -> D.Phobos.Random;
> > regexp -> D.Phobos.RegExp;
> > stdint -> D.Phobos.StandardTypes;
> > stream -> D.Phobos.Stream;
> > string -> D.Phobos.String;
> > switch -> D.Internal.Switch; (again the name!)
> > switcherr -> D.Exception.SwitchError;
> > syserror -> D.Exception.SystemError;
> > system -> D.Phobos.System;
> > thread -> D.Phobos.Thread;
> > time -> D.Phobos.Time;
> > ti_* -> D.Internal.*;
> > uri -> D.Phobos.URI;
> > utf -> D.Phobos.UTF8;
> > windows -> D.CRT.windows;
> > c.stdio -> D.CRT.stdio;
> > c.stdlib -> D.CRT.stdlib;
> > gc.* -> D.Internal.GC.*;
> >
> > dig would be put in the "D.Dig" package.  I could use "D.Dig.Main" for what "import dig" does now.  Or some other prefix than D.  In any case, it's much clearer about what I'm referring to; when I type "string.tolower" it's ambiguous as to whether I'm referring to a module or an object, as I use it for both heavily.  XYZ.Phobos.String.tolower is completely unambiguous, and if it gets too much (module "string."'s used 43 times throughout dig, so that can happen) I can alias it to something more manageable.  And with full package names, I can alias more selectively - "private alias XYZ.Phobos P;" would allow me to use "P.String.tolower", which can often be enough.
> >
>
>

In article <befsfr$17ad$3@digitaldaemon.com>, Matthew Wilson wrote:
>> Using a different syntax for modules, e. g.
>>    c:stdio
>> the problem would go away. (I do not suggest this solution)
>>
> 
> Why not? I've never understood the reason for dropping :: in favour of . in Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to explicitly stipulate that something is a static method/variable (again, say in a template) how to I do it?
>
> Is there a reason that D has done away with :: or maybe just :   ?

According to Stroustrup (Design & Evolution of C++), C++ originally had only "." but "::" was introduced because it was common C practice to have a class and an object with the same name.  As this is not the case any more, "::" is simply not needed.  I can't figure out an example of an situation that would really require it, even in a template -- can you?

-Antti

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbgp4k9.pdc.jsykari@seth.hut.fi...
> In article <befsfr$17ad$3@digitaldaemon.com>, Matthew Wilson wrote:
> >> Using a different syntax for modules, e. g.
> >>    c:stdio
> >> the problem would go away. (I do not suggest this solution)
> >>
> >
> > Why not? I've never understood the reason for dropping :: in favour of .
in
> > Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to
explicitly
> > stipulate that something is a static method/variable (again, say in a
> > template) how to I do it?
> >
> > Is there a reason that D has done away with :: or maybe just :   ?
>
> According to Stroustrup (Design & Evolution of C++), C++ originally had only "." but "::" was introduced because it was common C practice to have a class and an object with the same name.  As this is not the case any more, "::" is simply not needed.  I can't figure out an example of an situation that would really require it, even in a template -- can you?
>
> -Antti

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbgp4k9.pdc.jsykari@seth.hut.fi...
> In article <befsfr$17ad$3@digitaldaemon.com>, Matthew Wilson wrote:
> >> Using a different syntax for modules, e. g.
> >>    c:stdio
> >> the problem would go away. (I do not suggest this solution)
> >>
> >
> > Why not? I've never understood the reason for dropping :: in favour of .
in
> > Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to
explicitly
> > stipulate that something is a static method/variable (again, say in a
> > template) how to I do it?
> >
> > Is there a reason that D has done away with :: or maybe just :   ?
>
> According to Stroustrup (Design & Evolution of C++), C++ originally had only "." but "::" was introduced because it was common C practice to have a class and an object with the same name.  As this is not the case any more, "::" is simply not needed.  I can't figure out an example of an situation that would really require it, even in a template -- can you?

"If I want to explicitly stipulate that something is a static method/variable (again, say in a template) how to I do it?"

>
> -Antti

Antti Sykäri wrote:
> 
> In article <befsfr$17ad$3@digitaldaemon.com>, Matthew Wilson wrote:
> >> Using a different syntax for modules, e. g.
> >>    c:stdio
> >> the problem would go away. (I do not suggest this solution)
> >>
> >
> > Why not? I've never understood the reason for dropping :: in favour of . in Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to explicitly stipulate that something is a static method/variable (again, say in a template) how to I do it?
> >
> > Is there a reason that D has done away with :: or maybe just :   ?
> 
> According to Stroustrup (Design & Evolution of C++), C++ originally had only "." but "::" was introduced because it was common C practice to have a class and an object with the same name.  As this is not the case any more, "::" is simply not needed.  I can't figure out an example of an situation that would really require it, even in a template -- can you?

You just have to go back to message one of this thread which I started with simple example where I stumbled over the problem: In short:

   char c;

is enough to get into trouble.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

In article <befsfr$17ad$3@digitaldaemon.com>, Matthew Wilson says...
>
>> Using a different syntax for modules, e. g.
>>    c:stdio
>> the problem would go away. (I do not suggest this solution)
>>
I agree, use a different syntax when necessary
>
>Why not? I've never understood the reason for dropping :: in favour of . in Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to explicitly stipulate that something is a static method/variable (again, say in a template) how to I do it?
>
>Is there a reason that D has done away with :: or maybe just :   ?

maybe it would be nice to change inheritance declares to
class B extends A
and interface to
class C implements I,J
like Java
so the ":" symbol would be available for more meaningful uses in statements

I doubt very much that it poses a parsing problem.  The larger conflict is with local label syntax.

Sean

"Mark T" <Mark_member@pathlink.com> wrote in message news:beov0g$15ln$1@digitaldaemon.com...
> In article <befsfr$17ad$3@digitaldaemon.com>, Matthew Wilson says...
> >
> >> Using a different syntax for modules, e. g.
> >>    c:stdio
> >> the problem would go away. (I do not suggest this solution)
> >>
> I agree, use a different syntax when necessary
> >
> >Why not? I've never understood the reason for dropping :: in favour of .
in
> >Java/.NET. After all, one can still use . to issue a static call on an instance in C++ if one needs this extra level of flexibility (say in a template). The reverse is not true in D/Java/.NET. If I want to
explicitly
> >stipulate that something is a static method/variable (again, say in a
> >template) how to I do it?
> >
> >Is there a reason that D has done away with :: or maybe just :   ?
>
> maybe it would be nice to change inheritance declares to
> class B extends A
> and interface to
> class C implements I,J
> like Java
> so the ":" symbol would be available for more meaningful uses in
statements