[phobos] next release (module useability)

[SHOO]

(2010/09/11 15:10), Jonathan M Davis wrote:
> On Friday 10 September 2010 22:40:58 SHOO wrote:
>> My question is simpler.
>>
>> I want to know the reason.
>>
>> time is a concept including date.
>> stopwatch/benchmark is a part of time, but it is not a part of date.
>> date is redundant if so.
>> Nonetheless what will the reason to add date to a module name be?
>
> Date functionality and time functionality are not necessarily the same in
> nature. You do different sorts when you're dealing with dates then when you're
> dealing with time. However, they do overlap a fair bit, so it can get a bit
> complicated and subjective.
>
> If you had std.date and std.time, then it would make sense for date-specific stuff
> to go in std.date and time-specific stuff to go in std.time. By having
> std.datetime, you're indicating that both the date-specific stuff and the time-
> specific stuff are together. A module named std.time doesn't necessarily have
> anything to do with date functionality, while std.datetime clearly has both (on
> the other hand std.date is arguably a bad name all around because while dates
> are times, times aren't necessarily dates).
>
> Now, dates _are_ time-related even if dates and times and their associated
> functionality are often dealt with quite differently, so it does make some sense
> to simply name the module std.time. However, it's not as immediately obvious
> that the module covers both date and time functionality. So, I think that
> std.datetime is a better name, but std.time would certainly work.
>

I think date is only an expression method of time that elapsed from 
0001/01/01. And the expression is easy to be understood by human beings.

std.date must go as soon as a replacement is done. Therefore, I think it 
is not necessary to consider std.date.


...Well, this story seems to be religion. The conclusion will not be given.
Because my opinion is not dissenting opinion to std.datetime, I think 
that either is good.

>> /* The reason of this question is because there was the doubt why naming
>> it is WAG for of the module of Phobos before in Japanese community. (The
>> subject at that time was "Why are std.file and std.path separated?") */
>
> Files and paths are related but are very different issues, so it doesn't surprise
> me at all that they're separate. On the other hand, it's not like it wouldn't
> make sense to have them together either, since they are very much related. But
> personally, I think that it makes more sense to have them separate.
>
> - Jonathan M Davis

I understand that std.path and std.file are separated very well.
The former is handling of character string simply, and the latter works 
on file system.
This is an example. Alternatively, std.getopt should be included in 
std.string or std.format should be included in std.string or std.utf 
should be included in std.conv or... Some module names look like chaos.
Naming should be better-scrutinized.


...However, to be frank, it is a trifling argument (for me).