On 2011-12-22 22:58, Andrei Alexandrescu wrote:
> On 12/22/11 3: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.
>
> 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
>

According to that the only problem seems to be the possibility of namespace collision.

-- 
/Jacob Carlborg

On 2011-12-22 17:22:59 +0000, Jacob Carlborg <doob@me.com> said:

> 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.

True, for serialization and other things. I'm not arguing against the feature.

What I am observing is that the the capabilities of D's runtime reflection are quite small compared to the footprint it has. We often hear on this list about how adding more information about functions and fields to typeinfo would bloat executables, yet I am under the impression the biggest part of that bloat (the code of all the virtual functions and whatever they call, even if you don't use those functions or even the class) is already part of each and every D executable, only we don't realize this because it is not exposed in the API, it just sits there in a mostly non-interpretable form (the vtable).

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 12/22/2011 11:32 AM, Jonathan M Davis wrote:
> 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,

Why not hide it?


> 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

Why is the efficiency of those functions important? I cannot think of an application that needs high performance timezone calculations. (Benchmark timing code does not need timezones.)


> that trying to
> avoid pulling in the TimeZone class just to avoid a few KB in the executable.

Kb in the executable does negatively impact performance.

The issue with something being only a few Kb is that when everyone thinks that, we wind up with a 1Mb "hello world" program.


> 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.

This conflates performance with allocated memory consumption and with static memory consumption.

I am talking about minimizing the executable file size on disk.

On 12/22/2011 10:13 AM, Jonathan M Davis wrote:
> 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.

I can't run the unittests on my old FreeBSD machine because it runs out of memory on std.datetime.

On 12/22/2011 9:36 AM, Andrei Alexandrescu wrote:
> 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 .*.

Checked exceptions is another feature that looks great on paper; it's only after years of use one discovers what a perniciously bad feature it is.

C++11 dropped it, too.

On 12/22/2011 11:25 AM, 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 have no idea why anyone would want this. (Is it because the file is too big to fit on a floppy disk? <g>)

On Thursday, December 22, 2011 13:38:51 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.

The only reason there are any hard-coded time zone names is that they're required to convert between the names used by Posix and those used by Windows. So, you _can't_ hook into the OS information and get them. Now, conceivably, you could move that information into a file and then parse the file when it's needed. That would obviously be less efficient, but creating a WindowsTimeZone or PosixTimeZone (which is what they'd most frequently be needed for) isn't exactly terribly efficient to begin with, since you have to read in the time zone information from from the disk or from the registry (which is probably on disk). So, that's not unreasonable.

> 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.

Well, the only time point type which only deals with time and not dates is TimeOfDay. Date, DateTime, and SysTime all deal with dates. You can't really get away from dealing with dates once your type holds more than 24 hours worth of time unless it's a duration as opposed to a time point. So, I really don't think that trying to split std.datetime into std.date and std.time makes much sense.

A better division would be to put SysTime in a module and TimeOfDay, Date, and DateTime in another. SysTime deals with the system time, has a time zone, and is intended for use with stuff which isn't calendar-based (timestamps and file times being good examples - anything where you need the absolute time when it occured), whereas the others don't have a time zone and therefore _are_ calendar-based. However, they all share common code, so they'd either need to duplicate that code or any modules that they're split up into need to be in the same package. They _could_ both be sitting in std directly, but that would give package access to completely unrelated functions. It's also possible that we'll have more date and/or time related modules in the future (for instance, having one for handling date-recurrence patterns would be nice), and if that occurs, it makes that much more sense to use a sub-package rather than std.

If we're splitting it up, there's also the question of how far we want to split it up. In the extreme case, we could put every struct and class in its own module, though that's going too far IMHO. But we're probably going to want to go farther than just splitting it in two. In addition to the benchmarking functionality, I'd like to see the time interval and range functionality in a separate module, and there's the question of whether the time zone stuff should be in its own module - though there's not  much point to the time zones without SysTime, so I'm not sure whether that's really valuable.

In any case, if we keep std.datetime and have it publicly import the other modules, we can split it up more or less however we like, but having a sub- package would make the most sense IMHO. My original std.datetime proposal was that way, but it was split badly, and we didn't really have any sub-package stuff in Phobos beyond the C stuff and Windows stuff at the time, but that has been slowly changing.

- Jonathan M Davis

Okay. Assuming that I'm going to try and make TimeZone opaque within SysTime, does that require a pointer rather than a reference? And I assume then that the time zone stuff would need to be in a separate module than SysTime. That being the case, how would SysTime be able to use the time zone without importing that module? Does the C++ solution of forward declaring it like

class TimeZone;

work in D?

- Jonathan M Davis

On 12/22/2011 2:00 PM, Jacob Carlborg wrote:
> I like the 1:1 mapping between file and modules, and folders and packages as well.

That feature is something that took some getting used to for a lot of people, but when they got used to it they preferred it.

On Thursday, December 22, 2011 10:29:59 Michel Fortin wrote:
> I'd tend to say that for general purpose time representation not involving local time, SysTime is suboptimal because it forces you to carry around a pointer to a time zone. Imagine an array of SysTime all in UTC and the space wasted with all those pointers referencing the UTC time zone object.
> 
> It should be very easy to make a separate type, let's say UTCTime, and allow SysTime to be constructed from it and to be implicitly converted to it (with alias this). Then put UTCTime in a different module from SysTime and you can deal with time in UTC without having to ever import the module with SysTime the time zone class it wants.
> 
> Then redefine all APIs not dealing with local time so they work with UTCTime instead of SysTime.

That could certainly be done, but it complicates things that much more. The idea, at least, of SysTime was that it would deal with all of the time zone stuff correctly without you having to worry about it unless you wanted to deal with the time zone stuff, in which case it would give you those capabilities. That requires having it to carry the time zone around.

Something like UTCTime would allow you to carry the time around without the time zone, but then anyone who wants to be able to do stuff like convert it to a string or get its year or anything like that is almost certainly going to want it in a particular time zone (probably local time) rather than UTC, so it increases the burden on the programmer to deal with something like UTCTime. If you're dealing with anything beyond comparing times or adding durations to them, you're going to need the time zone, and in most cases, UTC is not the one that people are going to want.

So, it harms usability IMHO to using something like UTCTime instead of SysTime, and just to save yourself the cost of the reference for the time zone? If you're _that_ worried about the space, you can always use a SysTime's stdTime property or toUnixTime and get an integral value to store. Granted, that's not as safe as something like UTCTime, since it's a naked number, but I really don't think that the cost of that reference is generally an issue.

- Jonathan M Davis