On Thursday, December 22, 2011 13:27:47 Andrei Alexandrescu wrote:
> 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.

Yes. And if we want to split up modules, publicly importing allows you to have a single place to import them all, which gives you more or less the same effect as if modules could be split into multiple files except that there's still a 1:1 correspondance between modules and files. So, I think that D's features do a fine job in that regard.

- Jonathan M Davis

On Thursday, December 22, 2011 10:26:27 Walter Bright wrote:
> 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.

Well, I have no idea how you'd do that in this case without hiding SysTime's implementation, since it has to call TimeZone's functions and therefore needs to know that they exist. They're polymorphic, so the exact type of the TimeZone could be unknown and unseen by SysTime, but it has to know about TimeZone. And if you hid the function bodies in an effort to make TimeZone's usage opaque, then you couldn't inline those functions anymore, and I would consider the efficiency of the functions to be more important that trying to avoid pulling in the TimeZone class just to avoid a few KB in the executable.

On Thursday, December 22, 2011 10:28:52 Walter Bright wrote:
> The time zone info can be lazily initialized only by those operations that need a time zone.

I don't think that that would really buy you anything. SysTime is default- initialized to use LocalTime, which is a singleton, so it's not like you're allocating a new TimeZone every time that you create or use a SysTime. Currently, the singleton is initialized by a static constructor, but that's going to be changed to be lazily initialized (which should get rid of the static constructors and their cost). So, there _is_ still some cost on the _first_ SysTime that gets created in the program, but after that, there isn't really. And doing a lazy initialization of the TimeZone within the SysTime in the case where the programmer does not specify a TimeZone would just increase the cost of most of SysTime's functions, since most of them would have to be checking whether the TimeZone had been initialized or not. With the singleton, such a check only occurs when the SysTime is created. And at some point, the singleton will probably be change to use emplace, which will allow it to completely avoid the GC heap, which will make the singleton cost that much less. So, the cost of the time zone from the perspective of execution speed is minimal. It sounds like it's just the fact that using a class increases the symbols in the executable that's the problem.

- Jonathan M Davis

On 12/22/11 1:32 PM, Jonathan M Davis wrote:
[snip]

Now that we got to talk about std.datetime, here are three things that I think we could do to make it more manageable.

1. Put files in data. I find it a tad awkward that we have time zone information in hardcoded strings inside the code. That means any such change would have us redistributed Phobos. I'm thinking a small data file would be more appropriate. Better yet, hook into OSs timezone information and let the OS worry about keeping that timely.

2. datetime == time + date. We could reduce std.datetime to "public import std.time, std.date;" and define:

(a) std.time -> everything having to do with sheer time information, no date-related oddities. That means the largest formalized interval would be the week.

(b) std.date -> all of the bizarre calendar stuff, dealing with months and more. Naturally std.date would use std.time.

3. Using loops in unittest instead of rote repetition - this is already underway. We could actually use data files with unittests if that's helpful.


Andrei

On 12/22/11 1:38 PM, Andrei Alexandrescu wrote:
> On 12/22/11 1:32 PM, Jonathan M Davis wrote:
> [snip]
>
> Now that we got to talk about std.datetime, here are three things that I
> think we could do to make it more manageable.
>
> 1. Put files in data.

I meant "put data in files" :o).

Also:

4. Move some of the benchmarking clock stuff from std.datetime into the fledgling std.benchmark. I'm on that.


Andrei

On 2011-12-22 18:36, 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 .*.
>
>
> Andrei

Really? I have not seen that. I have Eclipse 3.7.0 installed and it doesn't indicate and error with "import package.*;". Latest Eclipse is 3.7.1.

-- 
/Jacob Carlborg

On 12/22/11 2:32 PM, Jacob Carlborg wrote:
> Really? I have not seen that. I have Eclipse 3.7.0 installed and it
> doesn't indicate and error with "import package.*;". Latest Eclipse is
> 3.7.1.

Mine doesn't either, but if you use Eclipe's awesome (and weakly named) Organize Imports feature (Ctrl+Shift+O) by default it replaces the .* with the specific imports.  So I think Eclipse tends to discourage .* in general.

It makes sense to me that it's discouraged in Java; when reading third-party code (on the web for instance) it can be very difficult to tell where a type came from if it was part of a .* import.

On 2011-12-22 19:32, Walter Bright wrote:
> 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.

Exactly. But I'm referring to deserializing classes, I don't care what they're used for.

-- 
/Jacob Carlborg

On 12/22/11 3:32 PM, Jacob Carlborg wrote:
> On 2011-12-22 18:36, 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 .*.
>>
>>
>> Andrei
>
> Really? I have not seen that. I have Eclipse 3.7.0 installed and it
> doesn't indicate and error with "import package.*;". Latest Eclipse is
> 3.7.1.

I stand corrected (it was a while ago and my memory is hazy). Found a related discussion at http://stackoverflow.com/questions/1983435/eclipse-java-is-it-harmful-to-import-java-namespace

Andrei

On 2011-12-22 20:27, Andrei Alexandrescu wrote:
> 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

I like the 1:1 mapping between file and modules, and folders and packages as well.

-- 
/Jacob Carlborg

On 2011-12-22 20:38, Andrei Alexandrescu wrote:
> On 12/22/11 1:32 PM, Jonathan M Davis wrote:
> [snip]
>
> Now that we got to talk about std.datetime, here are three things that I
> think we could do to make it more manageable.
>
> 1. Put files in data. I find it a tad awkward that we have time zone
> information in hardcoded strings inside the code. That means any such
> change would have us redistributed Phobos. I'm thinking a small data
> file would be more appropriate. Better yet, hook into OSs timezone
> information and let the OS worry about keeping that timely.
>
> 2. datetime == time + date. We could reduce std.datetime to "public
> import std.time, std.date;" and define:
>
> (a) std.time -> everything having to do with sheer time information, no
> date-related oddities. That means the largest formalized interval would
> be the week.
>
> (b) std.date -> all of the bizarre calendar stuff, dealing with months
> and more. Naturally std.date would use std.time.

That seems like a good start to divide the module.

-- 
/Jacob Carlborg