(2010/09/09 9:48), Brad Roberts wrote:
> On Wed, 8 Sep 2010, Brad Roberts wrote:
>
>> What's the state of the union?  Er.. code base?
>>
>> IMHO, it's about time to consider cutting the next release.  Who has opinions on what's unfinished that they believe needs to be in it?
>
> The only regularly failing unit test is in phobos.  I filed a ticket for it the other day:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4824
>    - stopwatch unit tests fail intermitently
>
> I think it should be fixed before the release.

I fixed. But, I didn't test it. I don't have environment repro the problem. Will you confirm it if good?


BTW, I allow that revisions increase change without my permit because the module is a part of Phobos. Of course include a change of the module name. > Phobos Dev.

I think we should make some kind of decision regarding the date/time module(s) before releasing a Phobos version that contains std.stopwatch.

It would be silly to introduce a new module, only to deprecate it and move Stopwatch into std.time (or whatever) in the following release...

-Lars



On Thu, 2010-09-09 at 22:03 +0900, SHOO wrote:
> (2010/09/09 9:48), Brad Roberts wrote:
> > On Wed, 8 Sep 2010, Brad Roberts wrote:
> >
> >> What's the state of the union?  Er.. code base?
> >>
> >> IMHO, it's about time to consider cutting the next release.  Who has opinions on what's unfinished that they believe needs to be in it?
> >
> > The only regularly failing unit test is in phobos.  I filed a ticket for it the other day:
> >
> > http://d.puremagic.com/issues/show_bug.cgi?id=4824
> >    - stopwatch unit tests fail intermitently
> >
> > I think it should be fixed before the release.
> 
> I fixed. But, I didn't test it. I don't have environment repro the problem. Will you confirm it if good?
> 
> 
> BTW, I allow that revisions increase change without my permit because
> the module is a part of Phobos. Of course include a change of the module
> name. > Phobos Dev.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
> I think we should make some kind of decision regarding the date/time module(s) before releasing a Phobos version that contains std.stopwatch.
>
> It would be silly to introduce a new module, only to deprecate it and move Stopwatch into std.time (or whatever) in the following release...

Oh, I forgot that hasn't been resolved. Let's do this:

1. deprecate std.perf

2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now

3. Put a reminding comment in std.date that it'll be deprecated in favor of std.datetime

Does someone have the time to do so today?


Andrei

(2010/09/09 23:08), Andrei Alexandrescu wrote:
> On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:

> 2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now
>

Is there the clear reason to adopt std.datetime?
I think that std.time is better. Because name is short, and I think
"time" include concept of the "date".

> 3. Put a reminding comment in std.date that it'll be deprecated in favor of std.datetime
>

There is not a replacement yet. How about commenting after a replacement was completed? I think that announcing it by a document till then is better.

On Friday 10 September 2010 01:40:45 SHOO wrote:
> (2010/09/09 23:08), Andrei Alexandrescu wrote:
> > On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
> > 
> > 2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now
> 
> Is there the clear reason to adopt std.datetime?
> I think that std.time is better. Because name is short, and I think
> "time" include concept of the "date".

I think that datetime is more descriptive, and I have no problem with longer module names, so I think that I'd prefer it, but I don't really care all that much. The functionality is what's important, and if all date and time functionality is together, then it's not like it's going to be all that hard to find whether it's std.date, std.datetime, or std.time. Now, if we named it something like std.temporaltoolshed, std.temporalkitchensink, or std.temporalmishmash, then that would likely be a problem, but somehow I don't think that anyone is going for that sort of name. Any of the seriously suggested names thus far would likely work just fine.

- Jonathan M Davis

On Friday 10 September 2010 02:10:52 Jonathan M Davis wrote:
> On Friday 10 September 2010 01:40:45 SHOO wrote:
> > (2010/09/09 23:08), Andrei Alexandrescu wrote:
> > > On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
> > > 
> > > 2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now
> > 
> > Is there the clear reason to adopt std.datetime?
> > I think that std.time is better. Because name is short, and I think
> > "time" include concept of the "date".
> 
> I think that datetime is more descriptive, and I have no problem with
> longer module names, so I think that I'd prefer it, but I don't really
> care all that much. The functionality is what's important, and if all date
> and time functionality is together, then it's not like it's going to be
> all that hard to find whether it's std.date, std.datetime, or std.time.
> Now, if we named it something like std.temporaltoolshed,
> std.temporalkitchensink, or
> std.temporalmishmash, then that would likely be a problem, but somehow I
> don't think that anyone is going for that sort of name. Any of the
> seriously suggested names thus far would likely work just fine.
> 
> - Jonathan M Davis

You know, those ludicrous names that I came up with make me wonder about how good your module or library has to be in order for people to put up with its bad name. I mean, if you have a module that's useable with a reasonable name, it will get used. But if you have a really nasty module name, people will be less inclined to use it. If they have an alternative which is good enough and has a better name, they're more likely to use that. The worse the name, the less they're inclined to use your module.

However, the better that your module/library is in comparison to others, the more incentive there is to use it, bad name or no. So, you get this ratio of usefulness to useability (I'm just talk module naming useability at this point, but it could be expanded to general useability). The higher the usefulness, the greater the chance someone will use it; the lower the useability, the lower the chance that someone will use it. So, if you had an insanely useful module, you could give it a pretty bad name and it would still be used, but if you had a horrible module, it wouldn't matter how good the name was, it wouldn't be used. This begs the question of the threshold between a module being used do to its usefulness and being unused because of its bad name.

I bet that we could name std.stdio something pretty bad, and have it used all the time because people need it. e.g. std.inputoutputstuffthatyoudreallyliketodoandisdownrightuseful would still be used. People would complain bitterly (and with good reason), but it would get used because you pretty much need the functionality that it has. On the other hand, if you name std.algorithm std.reallycoolstuffthatyoudprefernottohavetodoyourself, I bet that a _lot_ fewer people would use it. Yes std.algorithm is highly useful, but I know enough programmers who would shy away from it already. If you give it a name like that, only its most ardent supporters will use it. Renaming something like std.functional or std.getopt would likely be even worse, since they're likely to be in even less demand than std.algorithm.

Now, I think that the reality of the matter is that the principle of useability relates far more to the contents of the module - how its functions are named, how they're used, etc. - matters far more than the name of the module, but I do think that it could be fairly interesting to see what the threshold of usage would be on a particular module with regards to its ration of usefulness to useability (be it its name or its contents). My guess is that, in general, low useability will kill a module far faster than its usefulness will get it used, which would just underline the importance of useability. I get the impression that programmers have tendency to reinvent the wheel very quickly if it looks like it's going to be too much trouble to use the wheel that they already have, or if they don't like it for whatever reason.

In any case. I suppose that I'm rambling on, but the thought occurred to me after thinking about my ridiculous module name suggestions, and I had to share. It would almost be challenging to see how good a module you had to write to get people to use a module with an atrocious module name like std.temporalmishmash.

- Jonathan M Davis

(2010/09/11 11:48), Jonathan M Davis wrote:
> On Friday 10 September 2010 02:10:52 Jonathan M Davis wrote:
>> On Friday 10 September 2010 01:40:45 SHOO wrote:
>>> (2010/09/09 23:08), Andrei Alexandrescu wrote:
>>>> On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
>>>>
>>>> 2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now
>>>
>>> Is there the clear reason to adopt std.datetime?
>>> I think that std.time is better. Because name is short, and I think
>>> "time" include concept of the "date".
>>
>> I think that datetime is more descriptive, and I have no problem with
>> longer module names, so I think that I'd prefer it, but I don't really
>> care all that much. The functionality is what's important, and if all date
>> and time functionality is together, then it's not like it's going to be
>> all that hard to find whether it's std.date, std.datetime, or std.time.
>> Now, if we named it something like std.temporaltoolshed,
>> std.temporalkitchensink, or
>> std.temporalmishmash, then that would likely be a problem, but somehow I
>> don't think that anyone is going for that sort of name. Any of the
>> seriously suggested names thus far would likely work just fine.
>>
>> - Jonathan M Davis
>
> You know, those ludicrous names that I came up with make me wonder about how good your module or library has to be in order for people to put up with its bad name. I mean, if you have a module that's useable with a reasonable name, it will get used. But if you have a really nasty module name, people will be less inclined to use it. If they have an alternative which is good enough and has a better name, they're more likely to use that. The worse the name, the less they're inclined to use your module.
>
> However, the better that your module/library is in comparison to others, the more incentive there is to use it, bad name or no. So, you get this ratio of usefulness to useability (I'm just talk module naming useability at this point, but it could be expanded to general useability). The higher the usefulness, the greater the chance someone will use it; the lower the useability, the lower the chance that someone will use it. So, if you had an insanely useful module, you could give it a pretty bad name and it would still be used, but if you had a horrible module, it wouldn't matter how good the name was, it wouldn't be used. This begs the question of the threshold between a module being used do to its usefulness and being unused because of its bad name.
>
> I bet that we could name std.stdio something pretty bad, and have it used all the time because people need it. e.g. std.inputoutputstuffthatyoudreallyliketodoandisdownrightuseful would still be used. People would complain bitterly (and with good reason), but it would get used because you pretty much need the functionality that it has. On the other hand, if you name std.algorithm std.reallycoolstuffthatyoudprefernottohavetodoyourself, I bet that a _lot_ fewer people would use it. Yes std.algorithm is highly useful, but I know enough programmers who would shy away from it already. If you give it a name like that, only its most ardent supporters will use it. Renaming something like std.functional or std.getopt would likely be even worse, since they're likely to be in even less demand than std.algorithm.
>
> Now, I think that the reality of the matter is that the principle of useability relates far more to the contents of the module - how its functions are named, how they're used, etc. - matters far more than the name of the module, but I do think that it could be fairly interesting to see what the threshold of usage would be on a particular module with regards to its ration of usefulness to useability (be it its name or its contents). My guess is that, in general, low useability will kill a module far faster than its usefulness will get it used, which would just underline the importance of useability. I get the impression that programmers have tendency to reinvent the wheel very quickly if it looks like it's going to be too much trouble to use the wheel that they already have, or if they don't like it for whatever reason.
>
> In any case. I suppose that I'm rambling on, but the thought occurred to me after thinking about my ridiculous module name suggestions, and I had to share. It would almost be challenging to see how good a module you had to write to get people to use a module with an atrocious module name like std.temporalmishmash.
>
> - Jonathan M Davis

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?

/* 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?") */

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.

> /* 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

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

On Saturday 11 September 2010 11:07:57 SHOO wrote:
> (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.

I wasn't really considering std.date as it is so much as a potential name in general. And given that std.date is more time-centric than date-centric, it arguably wasn't the best name to begin with. But it is what it is. Certainly, regardless of what we do with the names, the code that is currently in std.date will need to be deprecated or outright removed as soon as we have a viable replacement.

- Jonathan M Davis