On 4/27/2014 1:55 AM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:ljie28$7ei$1@digitalmars.com...
>
>> I am not seeing an actual proposal. If I missed it, please point me at it.
>
> You missed it.  `pragma(cpp_namespace, "...")` and all enclosed C++ declarations
> are mangled accordingly.  No other changes.

Ok, I saw that, and replied to it earlier this thread.

On 27/04/14 21:39, Walter Bright wrote:

> std.datetime is a giant kitchen sink. This is not the best way to
> organize things. Using smaller modules under packages is a much better way.

It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :)

-- 
/Jacob Carlborg

On 4/27/2014 11:17 PM, Jacob Carlborg wrote:
> On 27/04/14 21:39, Walter Bright wrote:
>
>> std.datetime is a giant kitchen sink. This is not the best way to
>> organize things. Using smaller modules under packages is a much better way.
>
> It's taken an amazingly long time for the core developers to realize this. I'm
> glad it's happened tough :)
>

We've known it for a long time, but nobody has done anything about it.

For example, the new package.d feature was specifically designed so that long modules can be broken up without breaking user code. Nobody has yet modified any Phobos code to actually do this.

On 4/27/14, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> When you find yourself doing things like that, seriously consider creating a
> new
> module to do it, called "clock".

That's not reliable, because static imports are not enforced. It means anyone importing a module "clock" will automatically have all symbols in "clock" imported into the current module, meaning this will work:

-----
import clock;

void main()
{
    auto time = currTime();  // note the lack of full qualification
}
-----

std.datetime rightly tries to discourage symbol pollution by default (it has a lot of symbols to begin with). So you're forced to write:

-----
import std.datetime;

void main()
{
    auto time = Clock.currTime();
}
-----

> Using smaller modules under packages is a much better way.

Sorry, but this is currently impossible. Programmers will always use the feature that actually works over a feature that might work some day. Modules have too many open bugs right now, such as leaking selective imports, private visibility, non-propagating package access, etc etc.

If you ever try to build a larger library you'll immediately become aware of these issues.

On 4/28/14, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :)

Really? I've seen everyone complain about it from day 1.

"Walter Bright"  wrote in message news:ljjmi6$16nk$1@digitalmars.com...

> Ok, I saw that, and replied to it earlier this thread.

Yes, but you seemed to miss the point.

> Having a pragma to just add mangling doesn't deal with problems like:
>
>      namespace N { int foo(); }
>      namespace M { int foo(); }
>
>      foo();  // how to specify which one gets called?
>
> I.e. only addressing name mangling does not scale. Need actual scopes, too.

We have MODULES to deal with conflicts.  We do NOT need to add a new type of scope to D just for C++ namespaces.

You deal with conflicts the SAME WAY you do with normal symbols - put them in different modules.

This is more powerful, because it doesn't force you to match the namespace layout in your D code. 

On Sun, 27 Apr 2014 23:49:41 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 4/27/2014 11:17 PM, Jacob Carlborg wrote:
> > On 27/04/14 21:39, Walter Bright wrote:
> >
> >> std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way.
> >
> > It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :)
> >
> 
> We've known it for a long time, but nobody has done anything about it.
> 
> For example, the new package.d feature was specifically designed so that long modules can be broken up without breaking user code. Nobody has yet modified any Phobos code to actually do this.

It's my fault as far as std.datetime goes. I had it mostly done last summer but then didn't have time to finish it, and enough has changed since then that I'm going to have to start over. And life has been quite hectic for me, making it so that I'm not getting to stuff like this as soon as I'd like. I hope to get back to it soon though. It's long past time that it get done.

- Jonathan M Davis

On 4/28/14, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> It's my fault as far as std.datetime goes. I had it mostly done last summer but then didn't have time to finish it, and enough has changed since then that I'm going to have to start over. And life has been quite hectic for me, making it so that I'm not getting to stuff like this as soon as I'd like. I hope to get back to it soon though. It's long past time that it get done.

Hey if you're out of time, let us know. Maybe give us just a small guide on where to move things around, and we'll take it from there and split it up into packages.

On 28/04/14 10:14, Andrej Mitrovic via Digitalmars-d wrote:

> Really? I've seen everyone complain about it from day 1.

When I started to complain about having too big modules nobody agreed.

-- 
/Jacob Carlborg

On 28/04/14 08:49, Walter Bright wrote:

> We've known it for a long time, but nobody has done anything about it.
>
> For example, the new package.d feature was specifically designed so that
> long modules can be broken up without breaking user code. Nobody has yet
> modified any Phobos code to actually do this.

I've been complaining about it long before people even started to thinking about package.d. Nobody agreed.

-- 
/Jacob Carlborg