> On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright <newshound2@digitalmars.com> wrote:
> 
> > 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>)

As for big module, my solutions are:
1) put related modules into a package (or directory)
2) add a module named all.d into the directory, and this module will import all the other modules publicly
3) now just import the *all* module when needed

For example, we have these modules
	std\datetime\all.d
	std\datetime\unit1.d
	std\datetime\unit2.d
	std\datetime\unit3.d
in a package called std.datetime (a directory named std\datetime)

To import the datetime package, we use this:
	import std.datetime.all;

So, my suggestions are:
1) can we import the *all* module defaultly (maybe it called another module name) ?
   Then, we can use "import std.datetime;" instead of "import std.datetime.all;".
2) The compiler can recognise the importing module as a package, then import all modules in the package automaticly (including sub-package or not ?)
   Then, we just use "import std;" to import all the modules in the standard package.

> 
> It's of most benefit (IMO) for the Visual Studio IDE/GUI designer code. The automated code generation goes into one source file, in a partial class.  The user defined code into another source file/partial class.  It makes life easier for both the developer and the GUI designer code itself.

Maybe this is another thing. The "partial class" seems important for auto-code-generation or function-extention.

----------
Zhang <bitworld@qq.com>

On 2011-12-25 04:05, zhang wrote:
>> On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright
>> <newshound2@digitalmars.com>  wrote:
>>
>>> 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>)
>
> As for big module, my solutions are:
> 1) put related modules into a package (or directory)
> 2) add a module named all.d into the directory, and this module will import all the other modules publicly
> 3) now just import the *all* module when needed

Here we have yet another example of some one who wants to use "import foo.*;".

-- 
/Jacob Carlborg

On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote:
> On 2011-12-25 04:05, zhang wrote:
>>> On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright
>>> <newshound2@digitalmars.com>  wrote:
>>>
>>>> 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>)
>>
>> As for big module, my solutions are:
>> 1) put related modules into a package (or directory)
>> 2) add a module named all.d into the directory, and this module will import all the other modules publicly
>> 3) now just import the *all* module when needed
>
> Here we have yet another example of some one who wants to use "import foo.*;".

I agree it would be nice to have a proper way to do this. Providing .all modules feels hacky and they need to be manually maintained - it also doesn't look as good.

The _really important thing_ to note here is, there are at least two kinds of D libraries when it comes to this issue. Some libraries, including Phobos, prefer putting a lot of stuff in one module rather than splitting it up into a package. But many other libraries prefer splitting a library over multiple modules and using the package system to tie them together.

Arguing over which approach is better comes down to a wide range of arguments, many quite subjective. I do not believe either approach is always better than the other. But I do believe it's important not to disregard the package approach, because it has advantages and adherents as well.

Right now, the language favours the single module approach. When packages are used instead, it's clunky to provide a convenient interface to the entire library, and it's not very intuitive to look for a ".all" module, which could be named anything.

I really like the idea of simply adding "import myPackage;", behaving like your average ".all" module.

Doing it this way solves at least three problems: No more clunky maintenance of convenience modules, big modules can later be split up into a package without breaking any client code, and we don't have to worry about a ".all" module for Phobos anymore (which is a suggestion that has been on the table several times).

On 2011-12-25 15:31, Jakob Ovrum wrote:
> On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote:
>> On 2011-12-25 04:05, zhang wrote:
>>>> On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright
>>>> <newshound2@digitalmars.com> wrote:
>>>>
>>>>> 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>)
>>>
>>> As for big module, my solutions are:
>>> 1) put related modules into a package (or directory)
>>> 2) add a module named all.d into the directory, and this module will
>>> import all the other modules publicly
>>> 3) now just import the *all* module when needed
>>
>> Here we have yet another example of some one who wants to use "import
>> foo.*;".
>
> I agree it would be nice to have a proper way to do this. Providing .all
> modules feels hacky and they need to be manually maintained - it also
> doesn't look as good.
>
> The _really important thing_ to note here is, there are at least two
> kinds of D libraries when it comes to this issue. Some libraries,
> including Phobos, prefer putting a lot of stuff in one module rather
> than splitting it up into a package. But many other libraries prefer
> splitting a library over multiple modules and using the package system
> to tie them together.
>
> Arguing over which approach is better comes down to a wide range of
> arguments, many quite subjective. I do not believe either approach is
> always better than the other. But I do believe it's important not to
> disregard the package approach, because it has advantages and adherents
> as well.
>
> Right now, the language favours the single module approach. When
> packages are used instead, it's clunky to provide a convenient interface
> to the entire library, and it's not very intuitive to look for a ".all"
> module, which could be named anything.
>
> I really like the idea of simply adding "import myPackage;", behaving
> like your average ".all" module.
>
> Doing it this way solves at least three problems: No more clunky
> maintenance of convenience modules, big modules can later be split up
> into a package without breaking any client code, and we don't have to
> worry about a ".all" module for Phobos anymore (which is a suggestion
> that has been on the table several times).

I'm not sure if I like that syntax because you wouldn't be able to tell the difference between importing a package and a module. But perhaps that's the point. Otherwise I agree.

-- 
/Jacob Carlborg

> >
> > I really like the idea of simply adding "import myPackage;", behaving like your average ".all" module.
> >
> > Doing it this way solves at least three problems: No more clunky maintenance of convenience modules, big modules can later be split up into a package without breaking any client code, and we don't have to worry about a ".all" module for Phobos anymore (which is a suggestion that has been on the table several times).
> 
> I'm not sure if I like that syntax because you wouldn't be able to tell the difference between importing a package and a module. But perhaps that's the point. Otherwise I agree.

The compiler should do this. A package is a directory, and a module just a file. When importing a package, the compiler will import all the modules in the package. The user doesn't care about this.
----------
Zhang <bitworld@qq.com>

> > As for big module, my solutions are:
> > 1) put related modules into a package (or directory)
> > 2) add a module named all.d into the directory, and this module will import all the other modules publicly
> > 3) now just import the *all* module when needed
> 
> Here we have yet another example of some one who wants to use "import foo.*;".
Yeah, a module is just a file. So, the file name wildcards seem can be use for module names.
----------
Zhang <bitworld@qq.com>

On 26/12/2011 12:51, zhang wrote:
<snip>
> The compiler should do this. A package is a directory, and a module just a file.
> When importing a package, the compiler will import all the modules in the package.
> The user doesn't care about this.

The user may well care if he/she is compiling someone else's project that imports the whole of some huge library despite using only a little bit of it, and this greatly increases the time it takes to compile. Both because of the time it takes to load the modules and because of having a larger symbol table to look through to resolve symbols as and when they are used.

Moreover, there may be modules that are intended primarily for a library's internal use, which would get imported and thereby clutter the symbol table.

Stewart.

> The core issue with not carrying around a time zone is that you get conversion problems. People do dumb stuff like convert time_t values from UTC to local time and back again, which causes all kinds of bugs.

Can you elaborate?

On Tuesday, December 27, 2011 11:19:03 Kagamin wrote:
> > The core issue with not carrying around a time zone is that you get conversion problems. People do dumb stuff like convert time_t values from UTC to local time and back again, which causes all kinds of bugs.
> 
> Can you elaborate?

1. Any time you do a conversion of any kind, you risk screwing it up. The less converting you do, the better.

2. With regards to time, DST is a killer. The reason for this is the fact that in the spring, one hour gets skipped, and in the fall one hour happens twice.

So, for example, let's say that in a particular time zone, at 2 am on March 3rd, the time goes to 3 am to apply DST. That means that the times of 2 am up to (but not including) 3 am do not exist. So, if you have the time 2:30 am in local time, what time is that in UTC? It's likely that the time code will assume that it's really 3:30 am, but the time that you're trying to convert doesn't technically exist, so there is not actually a right answer.

On the other hand, let's say that on 2 am on October 30th, the time falls back to 1:00 am taking that time zone out of DST. That means that the times of 1 am up to (but not including) 2 am happen twice. So, if you have the time 1:30 am in local time, what time is it in UTC? You can't know. It could be either. The time code is going to have to pick one or the other, but since 1:30 am is non- unique, it's not necessarily going to have the behavior which is correct for your program.

However, UTC can _always_ be correctly converted to other time zones whether they have DST or not. This is because UTC does not have DST and therefore does not have hours that don't exist or hours that happen twice. All of its times are unique. So, if you want to deal with time accurately and reliably, you need to always keep the time in UTC until you _need_ to convert it to local time (typically for display purposes but also for things like if you need to know something along the lines of what year that time is in in the local time zone).

Code which converts time back and forth between UTC and local time is asking for trouble. Even if it gets all of the conversions correct (or at least as correct as possible), it's going to have issues whenever a DST change occurs. That's one of the reasons why non-Windows OSes typically want to put the system clock in UTC and what it's so horrible that Windows normally puts the system clock in local time (another is the fact that applying DST can make it so that files from a few minutes ago are suddenly in the future if the file timestamps are in local time).

Where I work, we ended up with a bug where when you rewinded video and you were east of UTC, it would rewind one hour too far for each hour east of UTC that you were (so 2 hours east of UTC would rewind 2 hours and 1 second instead of 1 second). It turns out that the code had been converting a time value to UTC from local time when it was already in UTC (or it might have been the other way around - I don't recall exactly which at the moment). And that meant that it was subtracting the UTC offset from the time, causing it to go back too far. The only reason that we hadn't seen it in the US was because west of UTC, the time would have been in the future, which it couldn't do, so it ended up rewinding properly. Had that code completely avoided all of the time conversions that it was doing, it wouldn't have had any issues like that. And the fact that the bug only manifested in certain time zones (and _not_ the time zones that the code was being developed in) made it that much worse.

Times should be kept in UTC as much as possible and converted as little as possible. Anything else is asking for trouble. That's also one reason why it's good to have times be objects rather than naked numbers. It reduces the risk of people converting them incorrectly. SysTime mostly avoids the whole issue by encapsulating the time (in UTC) with a time zone, making it so that it generally "just works."

- Jonathan M Davis

On Tuesday, 27 December 2011 at 10:51:25 UTC, Jonathan M Davis wrote:
> On the other hand, let's say that on 2 am on October 30th, the time falls back to 1:00 am taking that time zone out of DST. That means that the times of 1 am up to (but not including) 2 am happen twice. So, if you have the time 1:30 am in local time, what time is it in UTC? You can't know. It could be either. The time code is going to have to pick one or the other, but since 1:30 am is non-
> unique, it's not necessarily going to have the behavior which is correct for your program.

how std.datetime works in this case? You need UTC value for SysTime.

> So, if you want to deal with time accurately and reliably, you need to always keep the time in UTC until you _need_ to convert it to local time (typically for display purposes but also for things like if you need to know something along the lines of what year that time is in in the local time zone).

True. That's why UTCtime proposed earlier makes perfect sense (I'd call it just `Time`).

> Code which converts time back and forth between UTC and local time is asking for trouble. Even if it gets all of the conversions correct (or at least as correct as possible), it's going to have issues whenever a DST change occurs. That's one of the reasons why non-Windows OSes typically want to put the system clock in UTC and what it's so horrible that Windows normally puts the system clock in local time

Are you sure?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724390%28v=vs.85%29.aspx

> Where I work, we ended up with a bug where when you rewinded video and you were east of UTC, it would rewind one hour too far for each hour east of UTC that you were (so 2 hours east of UTC would rewind 2 hours and 1 second instead of 1 second). It turns out that the code had been converting a time value to UTC from local time when it was already in UTC (or it might have been the other way around - I don't recall exactly which at the moment).

As far as I understand, this is a problem only for time values that bear no time zone information and not a problem for, say, UTCtime: when you convert UTCtime to UTC, you get the same value.

> Times should be kept in UTC as much as possible and converted as little as possible. Anything else is asking for trouble. That's also one reason why it's good to have times be objects rather than naked numbers. It reduces the risk of people converting them incorrectly. SysTime mostly avoids the whole issue by encapsulating the time (in UTC) with a time zone, making it so that it generally "just works."

One can convert std.datetime.SysTime value to local time just by adding a corresponding offset. That should be easy.