On 2011-12-22 17:50, Andrei Alexandrescu wrote:
> On 12/22/11 4:40 AM, Jacob Carlborg wrote:
>> It would break code, but it's better to break it sooner than later.
>> Seems more and more like D should support importing all modules in a
>> package, that Java does:
>>
>> import foo.*;
>
> I think this style is currently discouraged in Java.
>
> Andrei

Well, it seems like everyone wants it and there are several libraries that supports "import foo.all;" to include the whole "foo" package, including some of my own.

I know that it's used in the SWT library at least.

-- 
/Jacob Carlborg

On 2011-12-22 17:59, Andrei Alexandrescu wrote:
> On 12/22/11 6:50 AM, Jacob Carlborg wrote:
>> You should treat your testing code just as you treat your "regular"
>> code. Just as well designed, just as modularized, just as effective,
>> just as clean. The testing code is in fact just as much part of the
>> "regular" code as the rest of the code.
>
> This. YES. A liability of the current std.datetime is that it assumes
> that unittest code is exempt from the rules that apply to regular code.
> I am increasingly worried about that module. It has been argued that its
> sheer size is not a problem, but somehow the task of accounting for that
> has taken a life of its own - e.g. we can't test std.datetime like
> everything else in Phobos, it needs its own version.
>
> Andrei

That doesn't sound right. If std.datetime can't be tested like the rest of Phobos there's something quite seriously wrong with it.

-- 
/Jacob Carlborg

On 12/22/11 11:29 AM, Jacob Carlborg wrote:
> On 2011-12-22 17:50, Andrei Alexandrescu wrote:
>> On 12/22/11 4:40 AM, Jacob Carlborg wrote:
>>> It would break code, but it's better to break it sooner than later.
>>> Seems more and more like D should support importing all modules in a
>>> package, that Java does:
>>>
>>> import foo.*;
>>
>> I think this style is currently discouraged in Java.
>>
>> Andrei
>
> Well, it seems like everyone wants it and there are several libraries
> that supports "import foo.all;" to include the whole "foo" package,
> including some of my own.

The authors of Java apparently thought the same. It is _experience_ with the actual feature that turned out to be bad. Last time I used Eclipse it underlined with red the lines with .*.


Andrei

On Thursday, December 22, 2011 10:59:54 Andrei Alexandrescu wrote:
> This. YES. A liability of the current std.datetime is that it assumes that unittest code is exempt from the rules that apply to regular code.

I still don't agree with this at all, but there's no point in rehashing those arguments. I agreed to refactor the unit tests, and I've refactored some of them based on those complaints. I just haven't finished the job yet.

> I am increasingly worried about that module. It has been argued that its sheer size is not a problem, but somehow the task of accounting for that has taken a life of its own - e.g. we can't test std.datetime like everything else in Phobos, it needs its own version.

Any time that breaking it up has come up, it's been voted down. I don't personally find the size to be a maintainability issue at all, but it _is_ an issue as far as the documentation goes, since it makes the module harder to understand in spite of the fact that the basic design is fairly simple. Also, it's caused issues for Don when reducing compiler bugs, because he needs to strip out the unit tests, and there are a lot (and there still will be even if they're refactored, just because there's a lot to test). That's the main reason that the version identifier for the tests is still there.

I'm not against breaking up std.datetime as long as its broken into an actual package. Pieces of it can be broken out without that (e.g. the interval and range stuff), but I'm not sure that that would really reduce the size of the module enough to really fix the complaints on that front.

- Jonathan M Davis

On Thursday, December 22, 2011 18:33:46 Jacob Carlborg wrote:
> That doesn't sound right. If std.datetime can't be tested like the rest of Phobos there's something quite seriously wrong with it.

It can be, and it is. Previously, there were issues compiling it on Windows which caused the compiler to run out of memory. So, I added a version identifier for the unit tests which was disable on Windows. Those issues have been fixed, so the version identifier is now always enabled. I left it in, because it made Don's life easier when he was trying to reduce compiler bugs (since, without the unit tests, less gets pulled in, and less of std.datetime gets instantiated). The version identifier could be removed, but the ease of disabling the unit tests if necessary merited leaving it in.

- Jonathan M Davis

On 12/22/2011 3:03 AM, Jonathan M Davis wrote:
> I don't follow you. You mean use PIMPL for the time zone? I haven't a clue how
> you're going to do PIMPL without .di files,

PIMPL means you have an opaque pointer to something. It can be a function pointer, or a data pointer. It gets filled in at runtime. It has nothing to do with .di files.

This was used in the olden days for printf floating point formatting. If a program didn't use fp, it was bad to pull in the (large) floating point formatting package which printf must support. So, printf used an opaque pointer to the printf formatting package, which was null. If any other floating point code appeared in the source code, the compiler would emit a hook to initialize that pointer, and hence pull in the fp code.

In other words, it works a lot like a 'weak' reference.

I've done similar things to prevent pulling in multithreaded code when an app was single threaded.

(OOP programming with derived classes and such is a more formalized implementation of PIMPL. The user of the class has no idea which functions he actually is winding up calling.)

On 12/22/2011 3:03 AM, Jonathan M Davis wrote:
> On Thursday, December 22, 2011 02:12:31 Walter Bright wrote:
>> Timezone information is not necessary to measure elapsed time or relative
>> time, for example.
>
> The type requires it though. No, comparison doesn't require the time zone, but
> many (most?) of the other operations do. And the type can't be separated from
> the time zone. That's part of the whole point of how SysTime is designed. It
> holds its time internally in UTC and then uses the time zone to adjust the
> time whenever a property or other function is used which requires the time in
> that time zone. That way, you avoid all of the issues and bugs that result
> from converting the time. The cost of that is that you can't not have a time
> zone and use SysTime. So, if someone cares about saving that little bit of
> extra size in their executable by not using the time zone, they're going to
> have to use the C functions or design their own time code.

The time zone info can be lazily initialized only by those operations that need a time zone.

On 12/22/2011 9:22 AM, Jacob Carlborg wrote:
> On 2011-12-22 16:56, Michel Fortin wrote:
>> The benefit of referencing classes within module info: you can
>> instantiate them using Object.factory, if they have a default
>> constructor. We pay a heavy price compared to what we get with this very
>> limited runtime reflection.
>
> It's a really nice feature to have when implementing serialization.

Sure, but we need to be aware of class overhead, and not use classes unless necessary. I.e. a class shouldn't be used to merely create a namespace. Classes also should not be used if it is not intended to be a polymorphic type.

Andrei Alexandrescu wrote:
> On 12/22/11 11:29 AM, Jacob Carlborg wrote:
>> On 2011-12-22 17:50, Andrei Alexandrescu wrote:
>>> On 12/22/11 4:40 AM, Jacob Carlborg wrote:
>>>> It would break code, but it's better to break it sooner than later.
>>>> Seems more and more like D should support importing all modules in a
>>>> package, that Java does:
>>>>
>>>> import foo.*;
>>>
>>> I think this style is currently discouraged in Java.
>>>
>>> Andrei
>>
>> Well, it seems like everyone wants it and there are several libraries
>> that supports "import foo.all;" to include the whole "foo" package,
>> including some of my own.
>
> The authors of Java apparently thought the same. It is _experience_ with
> the actual feature that turned out to be bad. Last time I used Eclipse
> it underlined with red the lines with .*.

I wish D could support partial modules - partial as analogy to C#'s partial classes.

module std.datetime-unit1;
import std.datetime-unit2;
// dash allowed only in submodules with the same module name
...

module std.datetime-unit2;
import std.datetime-unit1;
...

// then

module whatever;
import std.datetime; // as usual

On 12/22/11 1:25 PM, Piotr Szturmaj wrote:
> I wish D could support partial modules - partial as analogy to C#'s
> partial classes.
>
> module std.datetime-unit1;
> import std.datetime-unit2;
> // dash allowed only in submodules with the same module name
> ....
>
> module std.datetime-unit2;
> import std.datetime-unit1;
> ....
>
> // then
>
> module whatever;
> import std.datetime; // as usual

I think there's a lot of mileage in the 1:1 correspondence between files and modules, and between directories and packages. We should keep it that way.

Andrei