Answering to an older point:

On 9/11/10 0:40 CDT, 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?

I think it's quite simple. First time I needed some time functions I searched the library home page for "time". Couldn't find any. It took me a while to find time-related functions inside std.date, and found the connection tenuous. Probably it would be equally uneasy for others, too.

If there is only std.time it is presumable that somebody looking for date functions would think of searching for "time".

But then "std.datetime" is 100% unambiguous. 10 people out of 10 would know what it contains. And it's really no extra effort for us, so why not?

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

It's a good point. The distinction between manipulating file names and file contents is valid, but academic. For scripts, you'd need to import both files most of the time anyway. What does WAG mean?

I think consolidating std.path and std.file into std.file would mark progress.


Andrei

On Tuesday, September 14, 2010 09:19:03 Andrei Alexandrescu wrote:
> > /* 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?") */
> 
> It's a good point. The distinction between manipulating file names and file contents is valid, but academic. For scripts, you'd need to import both files most of the time anyway. What does WAG mean?
> 
> I think consolidating std.path and std.file into std.file would mark progress.

Whereas I would argue that the distinction is a good one and that they should remain separate. Of course, if you're pretty much always going to use std.file if you use std.path, then it doesn't really gain much (other than making the docs easier to read) no matter how good a separation it is conceptually. Of course, you could use std.stdio for doing file stuff and use std.path with it, skipping std.file entirely, but that's more of an oddity of File living in std.stdio (presumably because stdin and stdout are Files) than because std.path and std.file don't generally get used together (since they likely do).

So, I'd tend to prefer that std.path and std.file be separate, but I can understand why someone would think it better for their functionality to be in one module.

- Jonathan M Davis

Funny, I was going to suggest just lumping all three (path, file, stdio).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100914/3308565b/attachment.html>

On Tuesday, September 14, 2010 11:11:16 David Simcha wrote:
> Funny, I was going to suggest just lumping all three (path, file, stdio).

Well, looking at the docs for std.stdio, it does some quite odd that it and std.file are separate. It seems quite natural to import one module for console I/O and another for file I/O, but given that the console I/O is essentially using file I/O to do its thing, it becomes quite odd for them to be separate. So, consolidating std.stdio and std.file starts looking like a good idea. And while I'd prefer that std.path stay separate, if std.stdio and std.file are a single module and that module is  pretty much always used if std.path is used, then having it separate becomes useful pretty much only because it keeps the docs separate and thus less cluttered. So, there is some merit in combining all three. Certainly, looking at the API for std.stdio, I'd say that it definitely should be combined with std.file.

- Jonathan M Davis

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100914/32a758b5/attachment.html>

On Tuesday 14 September 2010 18:21:37 Walter Bright wrote:
>  stdio is for buffered file I/O, file is for encapsulated file ops.

I confess that I see no point in separating code based on that, but regardless, the module names don't imply that their separation has anything to do with buffered I/O or encapsulated file ops. My first reaction from looking at the names is that std.stdio would be for console ops only and std.file would be for file ops. And since file I/O is still I/O, it would make sense for it to be in a module named std.stdio. Also, it seems to me that std.stdio is awfully small for a single module. So, combining them makes a lot of sense to me.

In any case, I don't think that the reason for the separation between std.stdio and std.file is at all obvious or that it ultimately makes much sense, and I'd love to see them combined. But obviously, it's not up to me.

- Jonathan M Davis

On Tue, Sep 14, 2010 at 07:30:36PM -0700, Jonathan M Davis wrote:
> In any case, I don't think that the reason for the separation between std.stdio and std.file is at all obvious or that it ultimately makes much sense, and I'd love to see them combined. But obviously, it's not up to me.


I really like the way

std.file.write
std.file.exists

etc, etc look. Most could be merged in with std.stdio, but the names wouldn't be as obvious anymore, since the module name doesn't say what it means.

On Tuesday 14 September 2010 19:35:05 Adam D. Ruppe wrote:
> On Tue, Sep 14, 2010 at 07:30:36PM -0700, Jonathan M Davis wrote:
> > In any case, I don't think that the reason for the separation between std.stdio and std.file is at all obvious or that it ultimately makes much sense, and I'd love to see them combined. But obviously, it's not up to me.
> 
> I really like the way
> 
> std.file.write
> std.file.exists
> 
> etc, etc look. Most could be merged in with std.stdio, but the names wouldn't be as obvious anymore, since the module name doesn't say what it means.

A good point, though I try and avoid needing to ever give the full names like that (I pretty much always would use write() and exists() rather than std.file.write() or std.file.exists()). However, having a the File struct in stdio feels seriously wrong. Also, the separation is confusing when you try and figure out what you need to do to actually open and read/write from/to files.

- Jonathan M Davis

On Tue, 2010-09-14 at 18:21 -0700, Walter Bright wrote:
> stdio is for buffered file I/O, file is for encapsulated file ops.

...and std.path is just string manipulation.  I have to say, I really like the way these three modules are separated now.

Before, I used to make mistakes such as importing std.file to use File, or importing std.path to use getcwd().   But then, one day, I understood why the modules are organised the way they are, and I don't think I've ever made such mistakes again.

Perhaps the documentation of the modules could be improved to help users understand this right away?  Suggestions:

std.file:
        This module is for encapsulated file operations, such as
        copying, deleting, and renaming files, as well as directory
        manipulation.  It also contains functions that read and write
        entire files in one operation.

        See_also:
        std.stdio, for general I/O-related functionality.
        std.path, for path-related string operations.


std.stdio:
        bla bla bla...

        See_also:
        std.file, which contains methods to read and write entire files
        in one operation.


std.path:
        bla bla bla...

        See_also:
        std.file, for functions that perform actual filesystem
        operations (copying, renaming, deleting, etc.).

-Lars

(2010/09/15 1:19), Andrei Alexandrescu wrote:
> Answering to an older point:
>
> On 9/11/10 0:40 CDT, 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?
>
> I think it's quite simple. First time I needed some time functions I searched the library home page for "time". Couldn't find any. It took me a while to find time-related functions inside std.date, and found the connection tenuous. Probably it would be equally uneasy for others, too.
>
> If there is only std.time it is presumable that somebody looking for date functions would think of searching for "time".
>
> But then "std.datetime" is 100% unambiguous. 10 people out of 10 would know what it contains. And it's really no extra effort for us, so why not?
>

I see. Thank you for showing your thought.
I thought since C uses a name of time.h, the D can provide a similar
name then. However, the names had better be rather different because
this module should not have depended on functions of C.

>> /* 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?") */
>
> It's a good point. The distinction between manipulating file names and file contents is valid, but academic. For scripts, you'd need to import both files most of the time anyway. What does WAG mean?
>
> I think consolidating std.path and std.file into std.file would mark progress.
>
>
> Andrei

WAG means "wild ass [arse] guess" in internet slang that I heard. It was
guessed that reason why std.path and std.file ware separated depend on
inspiration at that time.
I think that these features should be refined more, too. I am confused
that the handling of strings and path are mixed.