(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).
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
