"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EED5F39.7760CD6C@chello.at...
> 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.

One crucial point - overloading does not happen across modules. It only happens to names at the same scope. Hence, if you add a new module foo with foo.sqrt() in it, that will not overload with math.sqrt(). This is because lookups are done name first, then overload resolution.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bep4tm$1bbh$1@digitaldaemon.com...
> I doubt very much that it poses a parsing problem.  The larger conflict is with local label syntax.

It also causes parsing problems with ?: syntax.

Yes, something like this should be done. I hope to get to it soon. -Walter

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bd1r3s$1s87$1@digitaldaemon.com...
> Walter wrote:
> > "Mark T" <Mark_member@pathlink.com> wrote in message news:bc9r3j$1bpm$1@digitaldaemon.com...
> >
> >>In article <bc3343$1dgn$1@digitaldaemon.com>, Walter says...
> >>
> >>>In the next version, I've added a module scope operator, ., which
should
> >>>resolve this problem properly, as in:
> >>>.c.stdio.fgets(&buf[0],buf.size,.c.stdio.stdin);
> >>>
> >>>It works analogously to the C++ global scope operator ::.
> >>
> >>IMHO this looks really ugly,  doesn't "import" give enough info to avoid
> >
> > this ??
> >
> > No.
> >
> >
> >>I thought the whole idea was to be cleaner than C++.
> >
> >
> > If there's a better way to resolve that problem, I want to know about
it!
>
> 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.
>