None here. But perhaps it would be worthwhile to rename D stdin and
stdout for
clarity anyway. din and dout follows the C++ convention, though I can't
say I
much like it. Any other suggestions?

I have my "douts" about those names, I must say. :-P
--anders

yeah, that is kindof clunky. But I don't think a rename is enough. There's
something bigger that should be discussed - or at least I hope Walter will
think about. My own worry is that D has two "standard" io mechanisms. Say
someone is writing a book introducing D (hypothetical, I know!). The first
program is presumably something like
import std.stdio;
int main(char[][] args) {
writefln("hello world");
return 0;
}
or, if printf is still in object.d and the author prefer's C it will be
int main() {
printf("hello world\n");
return 0;
}
I hope, though, that the author is trying to teach the reader good habits
and will use writefln instead. My question is what is next program that
writes hello world to a file? I'm guessing it will be
import std.stdio;
int main(char[][] args) {
FILE* f = fopen("out.txt","w");
fwritefln(f,"hello world");
fclose(f);
return 0;
}
The alternative today would be
import std.stream;
int main(char[][] args) {
File f = new File("out.txt",FileMode.OutNew);
f.writefln("hello world");
f.close();
return 0;
}
The two versions have advantages and disadvantages - but the author has to
choose one or the other. And if they choose to import different modules to
direct io to a file as opposed to the console then that needs explanation.
So if std.stdio talks about FILE* I'm tempted to say D's primary "stream" io
is FILE* and uses writef and fwrite/fread (a nice symmetry there, actually).
It's possible we could remove std.stream.stdout etc and add a class that
wraps FILE* so that if a user really wanted a stream interface to stdio they
could make one using something like new CFile(stdout). Basically streams
would become a class interface to FILE* or wrapper around non-FILE* io.
Another way of phrasing the issue is to put oneself in the shoes of a
library writer who is writing a feature that takes a file input. How do they
declare their function? Does it take a FILE*, File or mango file class or a
callback like std.format or even something else? I think the D community
would benefit from some clarity on what D's io story is (which also gets to
clarity on phobos in general but that's a bigger question).

Mango.io takes care of all this, Ben <g>
All files, sockets, etc are all instances of Conduits. Once you have a
conduit instance, you can read/write it directly, or you can wrap it with a
Buffer. Buffers can be read/written directly, or they in turn can be wrapped
with a variety of readers & writers.
Mango.io provides pre-built Stdin, Stderr, and Stdout reader/writer
instances, which one can use in a variety of different ways:
# Stdout << 10 << " green bottles";
#
# Stdout (10) (" green bottles");
#
# Stdout.print ("%d green bottles", 10);
Note that Stdout is nothing more than an instance of Writer ~ you can do the
above with any type of Conduit endpoint, an array within memory, or a
Memory-Mapped version of a file.
In addition, the classes representing files, paths, etc are fully cohesive ~
there's no overlap of functionality or confusion over what to use in any
given context (as you note that there is within Phobos). It's all very
simple.
Mango.io also supports the configuration of char/wchar/dchar encoders &
decoders, directly within the I/O layer itself. It also supports the full
range of native D types, plus the full range of native one-dimensional array
types, along with the ability to bind one's own classes directly to the I/O
system. In fact, the Mango version of printf supports all those native
arrays too. Reader instances know how to deal with arrays correctly, and
there are pluggable performance enhancements available to manage, or
sidestep, related memory allocation. Combined with class serialization, it's
a potent yet surprisingly simple package to use.
Mango has a bunch more besides:
- Wrappers around the unicode ICU project (with a very usable String module)
- A Log4D logging package, with hooks into Chainsaw plus a dynamic
application monitor/manager.
- Clustered caching and queuing
- High performance HTTP server, with Servlet engine
- HTTP client
Each of which use the mango.io package extensively.
"Ben Hinkle" <bhinkle mathworks.com>...

yeah, that is kindof clunky. But I don't think a rename is enough. There's
something bigger that should be discussed - or at least I hope Walter will
think about. My own worry is that D has two "standard" io mechanisms. Say
someone is writing a book introducing D (hypothetical, I know!). The first
program is presumably something like
import std.stdio;
int main(char[][] args) {
writefln("hello world");
return 0;
}
or, if printf is still in object.d and the author prefer's C it will be
int main() {
printf("hello world\n");
return 0;
}
I hope, though, that the author is trying to teach the reader good habits
and will use writefln instead. My question is what is next program that
writes hello world to a file? I'm guessing it will be
import std.stdio;
int main(char[][] args) {
FILE* f = fopen("out.txt","w");
fwritefln(f,"hello world");
fclose(f);
return 0;
}
The alternative today would be
import std.stream;
int main(char[][] args) {
File f = new File("out.txt",FileMode.OutNew);
f.writefln("hello world");
f.close();
return 0;
}
The two versions have advantages and disadvantages - but the author has to
choose one or the other. And if they choose to import different modules to
direct io to a file as opposed to the console then that needs explanation.
So if std.stdio talks about FILE* I'm tempted to say D's primary "stream"

is FILE* and uses writef and fwrite/fread (a nice symmetry there,

It's possible we could remove std.stream.stdout etc and add a class that
wraps FILE* so that if a user really wanted a stream interface to stdio

could make one using something like new CFile(stdout). Basically streams
would become a class interface to FILE* or wrapper around non-FILE* io.
Another way of phrasing the issue is to put oneself in the shoes of a
library writer who is writing a feature that takes a file input. How do

declare their function? Does it take a FILE*, File or mango file class or

callback like std.format or even something else? I think the D community
would benefit from some clarity on what D's io story is (which also gets

Another way of phrasing the issue is to put oneself in the shoes of a
library writer who is writing a feature that takes a file input. How do they
declare their function? Does it take a FILE*, File or mango file class or a
callback like std.format or even something else? I think the D community
would benefit from some clarity on what D's io story is (which also gets to
clarity on phobos in general but that's a bigger question).

I'm part of the camp that thinks that std.c.stdio is C and not D, so
when I do things like that I use std.stream. Weird thing is that I
prefer writef() over stdout.writef() ... Hehe...
--
Carlos Santander Bernal

Another way of phrasing the issue is to put oneself in the shoes of a
library writer who is writing a feature that takes a file input. How do
they declare their function? Does it take a FILE*, File or mango file
class or a callback like std.format or even something else? I think the D
community would benefit from some clarity on what D's io story is (which
also gets to clarity on phobos in general but that's a bigger question).

I'm part of the camp that thinks that std.c.stdio is C and not D, so when
I do things like that I use std.stream. Weird thing is that I prefer
writef() over stdout.writef() ... Hehe...

same here. Actually I typically use printf since it is in object.d so I
don't have to import anything and it handles pointers better than writef
(when I'm debugging and I have an object x and I want to print the address
of x I can't use writef - very annoying).

... Actually I typically use printf since it is in object.d so I
don't have to import anything and it handles pointers better than writef
(when I'm debugging and I have an object x and I want to print the address
of x I can't use writef - very annoying).

... Actually I typically use printf since it is in object.d so I
don't have to import anything and it handles pointers better than writef
(when I'm debugging and I have an object x and I want to print the
address
of x I can't use writef - very annoying).

writefln("Address of object is %08X", &x);

doesn't that print the address of the variable holding the reference to the
object? I'm looking for the equivalent to
printf("%p\n",x);

... Actually I typically use printf since it is in object.d so I
don't have to import anything and it handles pointers better than writef
(when I'm debugging and I have an object x and I want to print the
address
of x I can't use writef - very annoying).

writefln("Address of object is %08X", &x);

doesn't that print the address of the variable holding the reference to the
object? I'm looking for the equivalent to
printf("%p\n",x);

... Actually I typically use printf since it is in object.d so I
don't have to import anything and it handles pointers better than
writef
(when I'm debugging and I have an object x and I want to print the
address
of x I can't use writef - very annoying).

writefln("Address of object is %08X", &x);

doesn't that print the address of the variable holding the reference to
the
object? I'm looking for the equivalent to
printf("%p\n",x);

You're correct. I misunderstood your 'request'.
By the way, what would you do with the address of the object anyway?

without a debugger there's no other way to see what reference is stored in a
variable. I'm curious how people debug code involving objects otherwise
since I find myself quite often wondering just which variable refers to
which object.

I'm part of the camp that thinks that std.c.stdio is C and not D, so
when I do things like that I use std.stream. Weird thing is that I
prefer writef() over stdout.writef() ... Hehe...

I admit to often being naughty and adding an "alias stdout.writef
writef;" to the tops of my modules that use std.stream... I'm probably
just making a confusion trap for anyone else who reads that code, but it
saves me ty ping "stdout" a thousand times in debug-console-logging code.
-- Chris Sauls

I'm part of the camp that thinks that std.c.stdio is C and not D, so
when I do things like that I use std.stream. Weird thing is that I
prefer writef() over stdout.writef() ... Hehe...

I admit to often being naughty and adding an "alias stdout.writef
writef;" to the tops of my modules that use std.stream... I'm probably
just making a confusion trap for anyone else who reads that code, but it
saves me ty ping "stdout" a thousand times in debug-console-logging code.
-- Chris Sauls

I configure the editor to insert common "phrases" based upon characters
typed thus far (like intellisense), using a version of Emacs. I imagine you
could do something similar with other editors, such as binding some text to
a function-key?
Short names, combined with a lack of namespace isolation, often makes code
quite a bit harder to maintain over time. But, just recently I've started to
realize that the percentage of code with a lifespan of more than a semester
has been dropping at an increasing rate. Might the whole "long-term
maintenance" thing actually be a sinking ship?

Short names, combined with a lack of namespace isolation, often makes code
quite a bit harder to maintain over time. But, just recently I've started to
realize that the percentage of code with a lifespan of more than a semester
has been dropping at an increasing rate. Might the whole "long-term
maintenance" thing actually be a sinking ship?

No!
Wait till you are being paid to write code and then explain your code to
somebody else who has to maintain it. One can *never* write code that is
too clear or over supported by good practices.
--
Derek
Melbourne, Australia
27/05/2005 12:44:07 PM

Wait till you are being paid to write code and then explain your code to
somebody else who has to maintain it. One can *never* write code that is
too clear or over supported by good practices.

Some contractors working at an old job of mine admitted to me that they designed
complexity into their code to assure continued business with the client (and
long hours for even the simplest change). I had a look at a Monte Carlo app
they wrote at one point and it was the most horrifying bit of code I've ever
seen. Between things like this and the mistakes of inexperience, I wonder just
how much code out there is actually less cost-effective to maintain than to
rewrite from scratch.
Sean

Short names, combined with a lack of namespace isolation, often makes code
quite a bit harder to maintain over time. But, just recently I've started to
realize that the percentage of code with a lifespan of more than a semester
has been dropping at an increasing rate. Might the whole "long-term
maintenance" thing actually be a sinking ship?

That would be an interesting thing to find out. It's always been the case that
programs are used for far longer than the designers had ever planned, but it
wasn't until recently that the platforms applications are built on began to
change rapidly. Has the browser as a platform given rise to disposable code, or
will companies continue to use systems until they are years (or decades) out of
date?
Sean

quite a bit harder to maintain over time. But, just recently I've started

realize that the percentage of code with a lifespan of more than a

has been dropping at an increasing rate. Might the whole "long-term
maintenance" thing actually be a sinking ship?

That would be an interesting thing to find out. It's always been the case

programs are used for far longer than the designers had ever planned, but

wasn't until recently that the platforms applications are built on began

change rapidly. Has the browser as a platform given rise to disposable

will companies continue to use systems until they are years (or decades)

date?

Yes; interesting indeed. For example, I know of one /giant/ electronics
manufacturer (I imagine almost everyone owns something made by them) who
hire developers on a project by project basis only. There are no in-house
developers, therefore all internal knowledge of the code effectively dies
when the product ships. My understanding is that it's more cost-effective
overall for them to recreate than to maintain; but then the product itself
has a limited lifespan anyway. Disposable code for a disposable society <g>
Being the old-fart that I am, that concept almost blew my mind through my
nostrils.

quite a bit harder to maintain over time. But, just recently I've started

to

realize that the percentage of code with a lifespan of more than a

semester

has been dropping at an increasing rate. Might the whole "long-term
maintenance" thing actually be a sinking ship?

That would be an interesting thing to find out. It's always been the case

that

programs are used for far longer than the designers had ever planned, but

it

wasn't until recently that the platforms applications are built on began

to

change rapidly. Has the browser as a platform given rise to disposable

code, or

will companies continue to use systems until they are years (or decades)

out of

date?

Yes; interesting indeed. For example, I know of one /giant/ electronics
manufacturer (I imagine almost everyone owns something made by them) who
hire developers on a project by project basis only. There are no in-house
developers, therefore all internal knowledge of the code effectively dies
when the product ships. My understanding is that it's more cost-effective
overall for them to recreate than to maintain; but then the product itself
has a limited lifespan anyway. Disposable code for a disposable society <g>
Being the old-fart that I am, that concept almost blew my mind through my
nostrils.

I'm part of the camp that thinks that std.c.stdio is C and not D, so
when I do things like that I use std.stream. Weird thing is that I
prefer writef() over stdout.writef() ... Hehe...

I admit to often being naughty and adding an "alias stdout.writef
writef;" to the tops of my modules that use std.stream... I'm probably
just making a confusion trap for anyone else who reads that code, but it
saves me ty ping "stdout" a thousand times in debug-console-logging code.
-- Chris Sauls

I configure the editor to insert common "phrases" based upon characters
typed thus far (like intellisense), using a version of Emacs. I imagine you
could do something similar with other editors, such as binding some text to
a function-key?
Short names, combined with a lack of namespace isolation, often makes code
quite a bit harder to maintain over time. But, just recently I've started to
realize that the percentage of code with a lifespan of more than a semester
has been dropping at an increasing rate. Might the whole "long-term
maintenance" thing actually be a sinking ship?

Perhaps, but the day you start believing that and drop your good coding
habits, is the day your code will start lasting 10+ years! <g>
John Demme