www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why not std.io instead of std.stdio?

reply Michel Fortin <michel.fortin michelf.com> writes:
While it seems acceptable to use "stdio" in "std.c.stdio", since we're 
wrapping the C header of the same name, I see little justification in 
repeating the "std" in the module name for "std.stdio". Why not change 
it to "std.io"?

(same comment apply to other "std.std*" modules)

I first noticed the strangeness of this when I was new to D, but today 
I mistakenly wrote "import std.io;", which felt more natural, is 
shorter and reads way better than "import std.stdio;", which triggered 
the question.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 25 2009
next sibling parent reply Denis Koroskin <2korden gmail.com> writes:
Michel Fortin Wrote:


 While it seems acceptable to use "stdio" in "std.c.stdio", since we're 
 wrapping the C header of the same name, I see little justification in 
 repeating the "std" in the module name for "std.stdio". Why not change 
 it to "std.io"?
 
 (same comment apply to other "std.std*" modules)
 
 I first noticed the strangeness of this when I was new to D, but today 
 I mistakenly wrote "import std.io;", which felt more natural, is 
 shorter and reads way better than "import std.stdio;", which triggered 
 the question.
 
 -- 
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/
 


Nice question!

I also quite don't understand why Phobos doesn't take advantage of hierarchical
modules structure. For example, I/O is a large cathegory and a lot of elements
belongs to it. Console I/O is just one of example, but there is also network
I/O, DMA etc. I believe it is much better to put each independent element in
its own module (to reduce intermodular dependencies etc). For example, I put
each class in a separate module.

I believe it makes analyzing source code *a lot* easier.
Apr 25 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:

 I also quite don't understand why Phobos doesn't take advantage of
hierarchical modules structure. For example, I/O is a large cathegory and a lot
of elements belongs to it. Console I/O is just one of example, but there is
also network I/O, DMA etc. I believe it is much better to put each independent
element in its own module (to reduce intermodular dependencies etc). For
example, I put each class in a separate module. I believe it makes analyzing
source code *a lot* easier.<


I agree that std.io is better than std.stdio and I agree that a *bit* more
hierarchical structure in Phobos can be good (but we have to avoid the silly
deep nesting of Java libs), like adding one (1) more nesting level (only where
it's actually useful and using the current flat structure anywhere possible):
std.foo.bar.functionname

Regarding putting one class into a single module, D isn't Java (and Phobos
isn't Tango either), D allows you to group related public classes in to a
single module. This helps reading source code and reduces the number of files
to juggle around.
Like nested functions, grouping more related functions/classes/templates into a
single module gives you one more way to group things in a meaningful way.
When you import it's generally better to qualify imports anyway, helping you to
know where each name comes from:
from std.foo: bar, Baz.

Bye,
bearophile
Apr 25 2009
parent torhu <no spam.invalid> writes:
On 25.04.2009 19:41, bearophile wrote:

 I agree that std.io is better than std.stdio and I agree that a *bit* more
hierarchical structure in Phobos can be good (but we have to avoid the silly
deep nesting of Java libs), like adding one (1) more nesting level (only where
it's actually useful and using the current flat structure anywhere possible):
 std.foo.bar.functionname


I don't mind, as long as it doesn't lead to having to use renamed 
imports to avoid long FQN, like in Tango.  Keeping fully qualified names 
short is nice in some cases, like when avoiding the conflict between 
std.date.toString and std.conv.toString.

The reason Java gets away with using many directory levels is that 
everything is inside a class, so there's always a single-level 'local 
namespace'.  It's almost always either ClassName.member or 
objectName.member.


 When you import it's generally better to qualify imports anyway, helping you
to know where each name comes from:
 from std.foo: bar, Baz.


Yes, but selective imports often cause forward reference errors, so I've 
more or less stopped using them.  They also pollute the name space of 
modules importing modules that use them, which can be bad for libraries. 
  Of course, both issues are well known bugs.
Apr 25 2009
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Denis Koroskin (2korden gmail.com)'s article

 Michel Fortin Wrote:

 While it seems acceptable to use "stdio" in "std.c.stdio", since we're
 wrapping the C header of the same name, I see little justification in
 repeating the "std" in the module name for "std.stdio". Why not change
 it to "std.io"?

 (same comment apply to other "std.std*" modules)

 I first noticed the strangeness of this when I was new to D, but today
 I mistakenly wrote "import std.io;", which felt more natural, is
 shorter and reads way better than "import std.stdio;", which triggered
 the question.

 --
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/


 Nice question!
 I also quite don't understand why Phobos doesn't take advantage of hierarchical


modules structure. For example, I/O is a large cathegory and a lot of elements
belongs to it. Console I/O is just one of example, but there is also network
I/O,
DMA etc. I believe it is much better to put each independent element in its own
module (to reduce intermodular dependencies etc). For example, I put each class
in
a separate module.

 I believe it makes analyzing source code *a lot* easier.


Because then you have yet more stuff to remember to import.  Stuff that goes
together and is generally used at the same time shoudl be in the same module.
Apr 25 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 25 Apr 2009 11:47:53 -0400, Michel Fortin wrote:


 While it seems acceptable to use "stdio" in "std.c.stdio", since we're 
 wrapping the C header of the same name, I see little justification in 
 repeating the "std" in the module name for "std.stdio". Why not change 
 it to "std.io"?
 
 (same comment apply to other "std.std*" modules)
 
 I first noticed the strangeness of this when I was new to D, but today 
 I mistakenly wrote "import std.io;", which felt more natural, is 
 shorter and reads way better than "import std.stdio;", which triggered 
 the question.


The "std" is the package name. Here "std" is an abbreviation for "standard"
and in this context in means "a package that is supported by the compiler
manufacturer".

The "stdio" is the module within that package that contains standard I/O
routines. In this context, "standard" does not mean "ones supported by the
compiler manufacturer" but "ones that are commonly used" or such.

It is possible to have another I/O module in the same package that does not
contain standard I/O routines but implements non-standard, or specialized,
ones.

It seems that Mr Bright has a particular love for overloading the semantics
of words in order to minimize the number of unique words in play.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Apr 25 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Derek Parnell wrote:
<snip>

 The "std" is the package name. Here "std" is an abbreviation for "standard"
 and in this context in means "a package that is supported by the compiler
 manufacturer".


By the language standard, actually.  If a third-party compiler 
manufacturer throws in a library of its own, that would be in a 
different package.


 The "stdio" is the module within that package that contains standard I/O
 routines. In this context, "standard" does not mean "ones supported by the
 compiler manufacturer" but "ones that are commonly used" or such.


<snip>

So effectively, the C people decided to label these functions as the 
"standard" way of doing I/O, and D has copied this idea.

Was it ever intended as a reference to the streams that are the standard 
input and standard output?

Stewart.
Apr 25 2009