Maybe it sounds as a stupid question but I still wonder why to mimic C include name for standard input/output.

Regards,


--
Tom;
Argentina

Please note that discussion of this has already begun on d.D.announce.

If you're going to repost a question that's been posted on another 'group, you should always refer to pre-existing discussion.

Simply posting the original message verbatim as if it's new is nearly as bad as simple multiposting.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Tom wrote:
> Maybe it sounds as a stupid question but I still wonder why to mimic C include
> name for standard input/output.

I wonder the same. I also wonder why not...

std.unicode - instead of std.uni
std.c.ctype - instead of std.ctype
std.conversion - instead of std.conv
std.c.stream? - instead of std.cstream
std.memorymappedfile - instead of std.mmfile
...more?

And on a related note, why mimic C functions:

std.file:
isFile - instead of isfile
isDirectory - instead of isdir
...

std.string:
isWhite - instead of iswhite
stringToInt - instead of atoi
compare - instead of cmp
...

Sure it might be nice for C programmers, but a pain for others not familiar with a certain function in C. And using the C counterparts could be as easy as "using std.c.string", etc. I just find readability and consistency to be a huge plus in a library, especially one that is standard. If such changes would be accepted, or even considered, I'd be happy to do the work on this part of the library. I've even thought of re-doing it just for my personal use.

Lucas

Lucas Goss wrote:
> Tom wrote:
>> Maybe it sounds as a stupid question but I still wonder why to mimic C include
>> name for standard input/output.
> 
> I wonder the same. I also wonder why not...
> 
> std.unicode - instead of std.uni
> std.c.ctype - instead of std.ctype
> std.conversion - instead of std.conv
> std.c.stream? - instead of std.cstream
> std.memorymappedfile - instead of std.mmfile
> ...more?
<snip>

Because std.c.* is reserved for translations of C API headers.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Lucas Goss wrote:
>> I wonder the same. I also wonder why not...
>>
>> std.unicode - instead of std.uni
>> std.c.ctype - instead of std.ctype
>> std.conversion - instead of std.conv
>> std.c.stream? - instead of std.cstream
>> std.memorymappedfile - instead of std.mmfile
>> ...more?
> <snip>
> 
> Because std.c.* is reserved for translations of C API headers.

Ok that explains std.cstream, but isn't std.ctype a translation of ctype.h? Well I guess it doesn't use any C library, but it's essentially a copy ctype.h. The C libraries just seem to clutter up the niceness of D, and make it not so appealing to me. I can see the usefulness of having them to prototype functions until they can be redone later, but using the same naming just seems odd and makes the language feel outdated and hard to read. It also scares me a little because I'm sure someone will bring up the case that the naming can't be changed in the future because of backward compatibility. Makes me sad...

Lucas

Tom wrote:
> Maybe it sounds as a stupid question but I still wonder why to mimic C include
> name for standard input/output.
> 
> Regards,
> 
> 
> --
> Tom;
> Argentina

Here's a nice usage scenario for code refactoring capabilities. :)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Lucas Goss wrote:
> 
> Ok that explains std.cstream, but isn't std.ctype a translation of ctype.h? Well I guess it doesn't use any C library, but it's essentially a copy ctype.h. The C libraries just seem to clutter up the niceness of D, and make it not so appealing to me. I can see the usefulness of having them to prototype functions until they can be redone later, but using the same naming just seems odd and makes the language feel outdated and hard to read. It also scares me a little because I'm sure someone will bring up the case that the naming can't be changed in the future because of backward compatibility. Makes me sad...
> 
> Lucas

I agree here.  Leave the old C naming convention to std.c.* .  For all of the D functions, use more descriptive/intuitive and consistant names.  I hope the other major libraries (Ares, Mango) will take this to heart as well.  I noticed "atoi" in Mango.  atoi makes sense if you come from a C background, otherwise you'd have no idea what it does until you read the description.

Chad J wrote:
>  I hope the other major libraries (Ares, Mango) will take this to heart as well.  I noticed "atoi" in Mango.  atoi makes sense if you come from a C background, otherwise you'd have no idea what it does until you read the description.

Yeah I asked in the Ares forum about this, and the response was that Ares will stay as close as possible to DigitalMars for dmdrt and dmdgc:
http://www.dsource.org/forums/viewtopic.php?t=1468

So I'd like to try to get dmdrt and dmdgc changed before it's too late.

Lucas

I posted in announce and reposted there immediately as I post in there by mistake, then I posted here.

Sorry,

In article <e3qg7b$2val$1@digitaldaemon.com>, Stewart Gordon says...
>
>Please note that discussion of this has already begun on d.D.announce.
>
>If you're going to repost a question that's been posted on another 'group, you should always refer to pre-existing discussion.
>
>Simply posting the original message verbatim as if it's new is nearly as bad as simple multiposting.
>
>Stewart.
>
>-- 
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.1
>GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
>PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
>------END GEEK CODE BLOCK------
>
>My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

--
Tom;

On Tue, 9 May 2006 15:06:18 +0000 (UTC), Tom wrote:

> Maybe it sounds as a stupid question but I still wonder why to mimic C include name for standard input/output.
> 
> Regards,

"std.stdio" is the Standard I/O module in the "std" package. It allows for such things as "std.extio" which might be an Extended I/O module but still in the "std" package. In other words "stdio" describes an I/O module as 'standard' and "std." describes a package as 'standard'.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
10/05/2006 1:54:35 PM